MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [wsia] RE: [wsrp] Sessions and Transient Entities
Title: RE: [wsia] RE: [wsrp] Sessions and Transient
Entities
Excuse me for saying in advance that what follows is just my best
understanding at present, and represents my opinion, not a statement
of consensus even if it sounds like that's what I'm saying. It is just
easier for me to make statements than to hem and haw around a point in
order to find a very politically correct and inoffensive way to phrase
things.
I thought that consumers asked for sessions from producers who
provide portlets/entities, and it is the producer who gives a session
a sessionID. As of now we have only defined a session to the extent
that it is specific to a single producer to a single consumer to a
single end-user. We haven't successfully approached consensus other
than that AFAIK.
We have not yet adopted or reached consensus on how more than one
producer's portlets can be included in some concept of a shared
session. However...
A consumer can have as many portlets from as many producers as
needed for an individual end-user and how it manages that operation is
up to the consumer. I don't understand what the spec can do to make
that easier or more manageable. In the case of a number of
producers in sequence the problem would get worse with each
producer-consumer pairing.
Portlets from different producers don't need to know about each
other unless we burden the specification with a process for doing so.
That it would make some combinations of specific pairings easier to
manage for some consumers is without doubt, but we need to weigh the
cost to all.
Portlets from a single producer MAY know about each other at the
discretion of the producer. The consumer MAY ask to know if portlets
from a single producer have knowledge of each other in a session those
portlets share from that producer, and it is up to the producer to
allow the consumer to know whether those portlets share their state
information within that kind of shared session. IMO portlets from
different producers SHOULD NOT be required to share sessions.
Where 90 percent of the confusion over this issue has arisen is
from the notion that a consumer creates a session, which we have held
all along was a function of the producer because the producer has to
manage its sessions and entities in order to return the correct
portlet/entity to each consumer's requests and so gives it the
sessionID for that purpose. The need for a consumer to have the
ability through the specification to create a named session that
combines portlets from more than one producer is the real sticking
point, no matter how many ways you find to say it in different
words.
I suspect my position on that is apparent. However, as always, I
will go along with the consensus.
Ciao,
Rex
At 3:05 PM -0400 6/18/02, Eilon Reshef wrote:
Can you elaborate on why you believe it is useful for
the portlets not to know who they are sharing the state
with?