[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp] [wsia] [wsrp-wsia joint interfaces] agenda for Tuesday 11June
The beginnings of the process diagram is what was attempted in the table within section 2.1 (page 5-8) of the merged draft. Certainly provide feedback of how things could be clearer. I do not see the discussion Gil & Carsten leading as contradictory to my statement you quoted, but as attempting to work out in detail how the interaction would flow. We have attempted to make the lifecycle of both entities and sessions explicit so that a Consumer can apply knowledge that only it has with regards to the pairings that make sense for a particular page. On an orthogonal axis, only the Producer service knows whether there are constraints on whether all possible pairings make sense. There is beginning to be some discussion of whether the Producer can reasonable publish this information so that Consumer may take it into account as well. Regardless of the outcome of that discussion, my point was that a Producer service can certainly implement a policy governing how entities and sessions are paired for End-Users interacting through a particular Consumer as they ultimately manage the access a Consumer has to both entities and sessions. Rex Brooks <rexb@starbourne. To: Alan Kropp <akropp@epicentric.com>, com> "'wsrp@lists.oasis-open.org'" <wsrp@lists.oasis-open.org>, "'wsia@lists.oasis-open.org'" <wsia@lists.oasis-open.org> 06/11/2002 09:30 cc: AM Subject: Re: [wsrp] [wsia] [wsrp-wsia joint interfaces] agenda for Tuesday 11 June Without touching on the subsequent discussions already underway this morning, I find myself at sea wrt session management. In Rich's reply to Eilon's first comment on the merged document yesterday, Rich said, "To ask your questions about sessions in a stronger way: - Can a Consumer FORCE a Producer to do sessions in a manner the Producer does not want? This would include either requiring sharing OR requiring session independence. I think the answer has to be no. The Consumer does get to indicate preference (it is where the knowledge of the aggregated page lives and this is often important in guiding these decisions), but in the end the Producer is the one who creates and manages sessions..." I'm less concerned about the mechanics of a session than about the process, which I understood, going back to your diagram of states and arcs, Alan, as originating with a user request. This does not create a session, as I understand it, but does start the process, which moves up the chain of arcs to the producer, who creates the session when information starts to flow back down the chain of arcs of the end-user. The entity, as I understood it, was what we named the thingy which could be persistent or transient, was effectively an instance of the service between producer and consumer that gets activated by a session. We called it an entity to avoid the overloaded term instance. I understood entity to be the collection of properties, usually referred to as a container in WSRP terms, that could include a number of portlets. Much of the subsequent discussion between Carsten and Gil appears to be concerned with what looks to me to be a very muddy situation where consumers are now creating sessions and entities, which stands at odds with what I quoted above from Rich. I would have been happy to see the process diagram we spoke about, so that we can always be sure we are talking about the same things. I would really like to see that diagram. Ciao, Rex At 4:54 PM -0700 6/10/02, Alan Kropp wrote: >I think we'll have plenty of discussion around the merged document Rich and >Carsten put together. > >The two main issues I see that have arisen on the email lists are: > >1. What is the difference between transient entities and sessions, and is >there enough of a distinction to warrant including both in the >specification? > >2. There are efficiency concerns around the use of arrays in the method >signatures, basically to enable batched requests for network efficiency. > > >Call-in numbers: > USA Toll Free Number: 877-718-0936 > USA Toll Number: +1-712-923-6878 > PARTICIPANT PASSCODE: 563151 > > >Alan > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: <http://lists.oasis-open.org/ob/adm.pl> -- ---------------------------------------------------------------- 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