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 for Tuesday 30 July

Title: Re: [wsrp-interfaces][wsia][wsia-wsrp joint interfaces
Please excuse me if this was covered last Thursday, since I'm not part of that group, and listening in is just once telecom foo tar, for me if you know what I mean (transposition intentional).

Anyway, I'm only seeking a clarification. I had thought that it was performInteraction, as opposed to performAction for this functionality so that we could reserve performAction for eventing, when we get there. Perhaps I am misremembering. I don't personally have a preference, I just want to make sure that we don't inadvertently enshrine a bobbled term. (That is something I would be likely to do ;))

Everything else seems spot on.


At 4:27 PM -0700 7/29/02, Alan Kropp wrote:
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?
6.  How should we handle large SOAP attachments?  Compabitibility with .NET? 
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

Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com

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

Powered by eList eXpress LLC