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
Of course the portlets need to be prepared. But the portlet would not know
with what other portlet is should share the session. Only the consumer
knows this.
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/18/2002 06:36 |
| | AM |
| | Please respond to |
| | Eilon Reshef |
| | |
|---------+----------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Carsten Leue/Germany/IBM@IBMDE |
| cc: "'Michael Freedman'" <Michael.Freedman@oracle.com>, wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org |
| Subject: RE: [wsia] RE: [wsrp] Sessions and Transient Entities |
| |
| |
>---------------------------------------------------------------------------------------------------------------------------------------------|
Can you please elaborate on this - what would be a working scenario where a
Consumer decides to group portlets without the portlets pre-programmed to
be shareable?
-----Original Message-----
From: Carsten Leue [mailto:CLEUE@de.ibm.com]
Sent: Monday, June 17, 2002 12:21 PM
To: Eilon Reshef
Cc: 'Michael Freedman'; wsia@lists.oasis-open.org;
wsrp@lists.oasis-open.org
Subject: Re: [wsia] RE: [wsrp] Sessions and Transient Entities
Eilon -
because the consumer may want to decide which portlets to group
together in
a session. The producer would not be able to do so.
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/12/2002 02:49 |
| | 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: [wsrp] Sessions and Transient Entities
|
|
|
|
|
>
---------------------------------------------------------------------------------------------------------------------------------------------|
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)?
-----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:
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?Namely: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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC