[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsia] Re: RE: [wsrp] Sessions and Transient Entities
My opinion is that we should explicitly allow the consumer to create
sessions. This is simple and clear.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory Böblingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+---------------------------->
| | Rex Brooks |
| | <rexb@starbourne.|
| | com> |
| | |
| | 06/13/2002 05:53 |
| | AM |
| | Please respond to|
| | Rex Brooks |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Eilon Reshef <eilon.reshef@webcollage.com>, "'Rex Brooks'" <rexb@starbourne.com>, wsia@lists.oasis-open.org, |
| wsrp@lists.oasis-open.org |
| cc: |
| Subject: RE: [wsia] Re: RE: [wsrp] Sessions and Transient Entities |
| |
| |
>---------------------------------------------------------------------------------------------------------------------------------------------|
I hope we hear a few more opinions. I'm not clear that this makes the
interface simpler. If it does and we get consensus on it, I'll be happy to
go along with it. I agree with Rich for this version.
Rex
At 9:09 PM -0400 6/12/02, Eilon Reshef wrote:
Rex,
We are all trying to simplify the interface. If we can achieve the
same results (namely, Portlet Grouping/Scoping) without the need to
have an explicit interface for creating sessions, we are all better
off.
Eilon
-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: Wednesday, June 12, 2002 8:39 PM
To: Eilon Reshef; wsia@lists.oasis-open.org;
wsrp@lists.oasis-open.org
Subject: RE: [wsia] Re: RE: [wsrp] Sessions and Transient
Entities
I think we are already getting down to too much micromanaging.
Why should I care how a producer manages their portlets,
transient entities or any combinations thereof in one of my
sessions? As long as I get back what I ask for, I don't see
what difference it makes.
Ciao,
Rex
At 6:53 PM -0400 6/12/02, Eilon Reshef wrote:
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:richt2@us.ibm.com]
Sent: Wednesday, June 12, 2002 12:27 PM
To: wsia@lists.oasis-open.org;
wsrp@lists.oasis-open.org
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:
wsia@lists.oasis-open.org,
wsrp@lists.oasis-open.org
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: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>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
--
--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC