[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsia] RE: RE: [wsrp] Sessions and Transient Entities
I hope not.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory Böblingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+----------------------------->
| | Eilon Reshef |
| | <eilon.reshef@webc|
| | ollage.com> |
| | |
| | 06/13/2002 12:53 |
| | AM |
| | Please respond to |
| | Eilon Reshef |
| | |
|---------+----------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: "'MICHAEL.FREEDMAN'" <MICHAEL.FREEDMAN@oracle.com>, wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org |
| cc: |
| Subject: [wsia] RE: RE: [wsrp] Sessions and Transient Entities |
| |
| |
>---------------------------------------------------------------------------------------------------------------------------------------------|
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:MICHAEL.FREEDMAN@oracle.com]
Sent: Wednesday, June 12, 2002 10:58 AM
To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
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-
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:Michael.Freedman@oracle.com]
Sent: Tuesday,
June 11, 2002 7:43 PM
To: wsia@lists.oasis-open.org;
wsrp@lists.oasis-open.org
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC