OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [wsia] Re: RE: [wsrp] Sessions and Transient Entities



Let's defer the discussion on whether the consumer knows of the producer's
preferences to the F2F but let's try to come to an agreement that the
consumer can create multiple sessions and let the remote portlets share
data by letting them share the same session. In one extreme there would be
one session per user per producer, in the other extreme there would be one
session per user per remote portlet.


Best regards
Carsten Leue

-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B÷blingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401



|---------+---------------------------->
|         |           Rich             |
|         |           Thompson/Watson/I|
|         |           BM@IBMUS         |
|         |                            |
|         |           06/12/2002 06:27 |
|         |           PM               |
|         |           Please respond to|
|         |           Rich Thompson    |
|         |                            |
|---------+---------------------------->
  >---------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                             |
  |       To:       wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org                                                                        |
  |       cc:                                                                                                                                   |
  |       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