MHonArc v2.5.2 -->
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.
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC