RE: [wsrp-wsia] [I#192] SessionContext and Cookies conflict

[Andre Kramer <andre.kramer@eu.citrix.com>]

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>