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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

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


Subject: RE: [wsrp-interfaces][wsia][wsia-wsrp joint interfaces] Agenda fo rTuesday 30 July


 
-----Original Message-----
From: Alan Kropp [mailto:akropp@epicentric.com]
Sent: Tue, July 30, 2002 02:27
To: wsrp-interfaces@lists.oasis-open.org; wsia@lists.oasis-open.org
Subject: [wsrp-interfaces][wsia][wsia-wsrp joint interfaces] Agenda for T uesday 30 July

Over the last week, these are the main open questions and consensus items as I seen them.  I'd like to propose we work through as much of this as we can, and then roll the remainder (as well as any new questions) into the agenda for Thursday's call.  Mike, what do you think?
 
 
1.  Generic vs. specific release mechanism?  Discussion favors generic.
 
2.  HTTP cookies in the protocol?  Emerging consensus against.  But discussion does favor enforcing request consistency across the protocol, so how does this work in a load-balanced environment?  I think it's an implementation detail, but an important one that should be demonstrated asap in our proof-of-concept.
 
3.  New name for markupParameters:  navigationState?
 
4.  We seem to be arriving at the following consensus:  Producer always manages session state, passing a handle to the session to the Consumer to be used in subsequent requests.  A Consumer MAY explicitly request the creation of a session, especially if it knows it's going to multiplex requests to this service on behalf of many clients.
 
5.  For request lifecycle, Mike's proposal is as follows:  performAction redirects to the same portlet page and passes changed state as markupParams in the response.  On subsequent call to getMarkup, Consumer must embed the markupParams as the new navigational parameters for the request, so the portlet renders the correct (in sync with the most recent performAction) markup.
 
As a side-effect, this would require that performAction is always a blocking call.
 
There hasn't been much discussion on this since, what do people think?
[Gil Tayar] plus the fact that the Consumer must redirect after doing the performAction, and that the redirected page will do only getMarkup. 
[Gil Tayar] There is an additional question which has been discussed and which hasn't achieved consensus - whether getMarkup can return new markupParams. 
I am for Mike's proposition, and also think that getMarkup should not return new markupParams. Nevertheless, there is a scenario where getMarkup fails because the portlet's session has timed out, and thus should return new markupParams. I would propose doing this as an exception returned by getMarkup because Consumer in this case may have to return a redirect (just like in the performAction scenario) which is drastic considering that it's handling multiple getMarkups.
 
 
6.  How should we handle large SOAP attachments?  Compabitibility with .NET? 
[Gil Tayar] I would like to note that there are two SOAP attachments specifications battling between themselves. One is SOAP with attachments (W3) and the other is WS-Attachments.  I would hesitate to enter this political and defer the idea (which is a very good one!) to v2 of the standard.
 
7.  Factoring discussion.  This seems rather abstract, I think it needs to boil down to specifics in order to be useful to spec writers now.  Mike put up some proposals regarding the proper axes for factoring, as well as handling extensibility.  I tend to agree with his assessment.  Other proposals?
 
Call-in numbers:

USA Toll Free Number: 877-718-0936

USA Toll Number: +1-712-923-6878

PARTICIPANT PASSCODE: 563151

Alan



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


Powered by eList eXpress LLC