Title: Message
Wouldn't it be easier to just pass a key (say: portlet-group-id), that
allows the Producer to manage this more carefully than providing access to a
low-level mechanism such a session?
-----Original Message-----
From: Rich Thompson
[mailto:]
Sent: Wednesday, June 12, 2002 12:27
PM
To: ;
Subject: [wsia] Re: RE: [wsrp] Sessions
and Transient Entities
I would agree that supporting explicit creation of sessions is
easy means
for a Consumer to indicate an arbitrary
grouping that it would like to
establish. As the
Producer is ultimately managing the sessions, it can
always enforce whatever policies it would like on these groupings. I
would
recommend that this version of the spec not try
and define how a Producer
could expose such policies
to the Consumer, though we may want to revisit
this
question for future versions of the spec if scenarios are defined that
demonstrate value to the Consumer in knowing the Producer's
policies.
"MICHAEL.FREEDMAN"
<MICHAEL.FREEDMAN@
To: ,
oracle.com>
cc:
Subject: Re: RE: [wsrp] Sessions and Transient
Entities
06/12/2002
10:58
AM
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-
face="Trebuchet MS"
color=#0000ff>If a simple group-id within the
portlet UI
takes care of the issue (which I agree
with), why bother to allow the
Consumer
to create and manage sessions explicitly
(versus implicit creation by
the
Producer)?
class=122592900-12062002>
class=122592900-12062002>
-----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:
face="Trebuchet MS">Mike, class=731155222-11062002>
face="Trebuchet MS">Per your recent e-mails, I think that
the
approach makes sense. class=731155222-11062002> face
="Trebuchet MS">The only thing that concerns me is that
we
have two different mechanisms to handle what would seem
to be a very similar
scenario. class=731155222-11062002>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. class=731155222-11062002>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. class=731155222-11062002> face
="Trebuchet MS">(All, of course, assuming that the
portlets use sessions) class=731155222-11062002> face
="Trebuchet MS">The idea of the Consumer creating and
managing the segregation keys has the
scalability advantage that you mentioned.
class=731155222-11062002> class=731155222-11062002> face
="Trebuchet MS">Can't we use it to handle both
scenarios? class=731155222-11062002>
class=731155222-11062002> size=-1>Namely:
class=731155222-11062002> class=731155222-11062002> face
="Trebuchet MS">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. class=731155222-11062002> face
="Trebuchet MS">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. class=731155222-11062002> class=731155222-11062002>
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. class=731155222-11062002>
class=731155222-11062002> face="Trebuchet MS">Eilon
class=731155222-11062002> class=731155222-11062002>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
