OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


More than that - 
The cookie support in WSRP is a legacy thing, and intended to help
implementation.
The session support in WSRP is not legacy - it is intended as a part of the
WSRP capabilities and part of its basic model.

-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Thu, January 02, 2003 15: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