Re: [wsrp-interfaces][wsia][wsia-wsrp joint interfaces] Agenda for Tuesday 30 July

[Rex Brooks <rexb@starbourne.com>]

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.

Ciao,

Rex

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
> > PARTICIPANT PASSCODE: 563151
> > Alan

-- 

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