Title: Message
To clarify this a bit, (and, of course, to provoke a thought ;-) - would
you then feel that instead of calling the operation createSession we can
call it createPortletGroup, and assume that it's the portlet to
implementation this using a session or using some other lookup
table?
Eilon
-----Original Message-----
From: MICHAEL.FREEDMAN
[mailto:]
Sent: Wednesday, June 12, 2002
10:58 AM
To: ;
Subject: Re: RE: [wsrp] Sessions and
Transient Entities
Irs not so much a bother to allow rather its a no reason to prevent.
If a consumer wants to support such a thing they should be free to do so as
this would allow arbitrary groupings (from the perspective of the
producer).
-Mike-
-----Original
Message-----
From:
Michael Freedman
[mailto:]
Sent: Tuesday,
June 11,
2002 7:43 PM
To: ;
Subject: Re: [wsrp] Sessions and
Transient
Entities
Eilon,
I think
your
suggestion intermixes 2 different concepts -- that of session
identity and
that of instance/entity identity. My scenario 1
concerns itself with how
an instance/entity id can be used to segment
data within a session. My
scenario 2 concerns itself with how
distinct sessions can be
established/maintained. I suggested we
don't define a way for the
producer to describe its grouping
rules. Rather a consumer can choose to
support grouping (via a
mechanism its free to define) or leave it up to the
consumer to handle
internally (via perference/configuration data). So in
my
scenario 2, a consumer isn't responsible for separating the portlets into
different sessions. It merely is allowed to do so.
Portlets must
assume they aren't running in such environments --
rather they must assume
they run in a shared session world -- hence
they need an ID to do the proper
namespacing. As the consumer
doesn't know this grouping (because it
doesn't implement grouping) the
producer must provide its own UI for getting
these keys -- i.e. the
producer must provide a configuration/personalization
UI that allows a
group key to be specified for each of its portlets -- it can
then use
this "internal" group id to key/separate data in the shared session.
Just a long way of saying -- I don't buy your scenario 2. If the
consumer knows the grouping, I would rather the consumer maintain 2
discrete
sessions as this allows it to continue to pass the entity id
so each entity
can maintain entity specific data if necessary (i.e.
portlet A, B, B' in the
same session/group -- B and B' can keep their
data separate). If the
consumer doesn't know the grouping then
it controls things just like scenario
1. The producer is free to
define/manage finer granularity as described
above.
-Mike-
Eilon Reshef wrote:
Mike,Per your recent e-mails, I think that the
approach makes
sense.The only thing that concerns
me is that we
have two different mechanisms to handle what would
seem to be a very similar
scenario.Scenario 1:
If there are two occurrences of a single
portlet on a page, then as
you described it the portlet is
responsible for segregating the
occurrence-specific information,
using an additional key provided by the
portal.Scenario 2:
If there are two occurrences of a pair of
portlets, then suddenly the
portal is responsible for
segregating the two pairs by placing them in two
separate
sessions.(All, of course, assuming that
the
portlets use sessions)The idea of the Consumer
creating and
managing the segregation keys has the
scalability advantage that you
mentioned.Can't we use it to handle both
scenarios?In scenario 1, where there's
portlets A1
and A2, then the portal sends a key "1" when displaying
A1 and a key "2"
when displaying
A2. In scenario 2, when there's portlet
pairs
<A1, B1> and <A2, B2>, then the portal sends a key
"1" when
displaying A1 and B1 and the key "2" when displaying A2 and
B2.This would
allow the Producer to
create and manage the session id (and maybe even
create them only
when needed, instead of explicitly creating them up-front
as the
current draft suggests). The Consumer only has to take into account
that it may receive (and needs to re-send) a separate session id for
each
one of the keys.Eilon
