MHonArc v2.5.2 -->
wsia message
[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