[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] [I#192] SessionContext and Cookies conflict
Producers can now use the entityID&userContextID or entityInstanceKey to sub-scope the application session for entity / portlet private data. But we currently still have three behaviours to code and test (session cookie only; session ID only; both cookie and sessionIDs) when two (no cookie / sessionIDs; session cookie / no sessionIDs) cover all the use cases? Are any JSR 168 implementations going to now use producer generated sessionIDs? In my view, it would be better to reserve our protocol - level session mechanism (SessionContext & sessionIDs) for use cases that do not require the legacy application sharing support. regards, Andre -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: 02 January 2003 13:00 To: wsrp-wsia@lists.oasis-open.org Subject: Re: [wsrp-wsia] [I#192] SessionContext and Cookies conflict I do not see a conflict between these two. Cookies MAY be used to reference shared data and this might include a cookie referencing a shared session (other cookies are still possible though we have discussed them much less). A sessionID refers to private data for this instance of the entity. Therefore the conceptual scopes of these two is different. Since the protocol is defining support for both, Consumers will need to properly store and supply both types of references later. What would be the advantage of additional usage restrictions (it would be quite hard to verify compliance)? Rich Thompson Gil Tayar <Gil.Tayar@webcollage.com> 12/18/2002 04:03 AM To: wsrp-wsia@lists.oasis-open.org cc: Subject: [wsrp-wsia] [I#192] SessionContext and Cookies conflict Issue: 192 Status: Active Topic: interface Class: Technical Raised by: Andre Kramer Title: SessionContext and Cookies conflict Date Added: 18-Dec-2002 Document Section: v0.85/5.1.1 Description: Now that we have fully tied WSRP to HTTP cookies, a consumer has to handle two types of session: cookies returned by initCookie() and SessionContexts returned by markup interface responses. Means double the work for a consumer and likely to lead to errors. Resolution: Suggest that no SessionContext can be returned by producer when cookie protocol is "perUser" or "perGroup" (e.g. JSR168 Portlets). No sessionID is then required to be supplied, with cookies in use, by a consumer in RuntimeContext. SessionContext then becomes our (non-http, transport independent) protocol session mechanism if and only if cookie protocol is "none". ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC