[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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".
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC