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


Help: OASIS Mailing Lists Help | MarkMail Help

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

You might argue of whether this case the entities have been "pre-programmed
to be shareable", but we have been involved in a number of projects where
"modules" have been written such that a base set of data is in a common
format with each module free to extend this "data model" in its own manner.
What set of these may be sharing a single session was then determined by
the encapsulating page definition. By giving a set of these modules a
common session, the overlay of their data models produced a union where the
some set of things was shared without the modules having to know or care
about the sharing.

                      Eilon Reshef                                                                                   
                      <eilon.reshef@webc        To:       Carsten Leue/Germany/IBM@IBMDE                             
                      ollage.com>               cc:       "'Michael Freedman'" <Michael.Freedman@oracle.com>,        
                                                 wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org                
                      06/18/2002 12:36          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;
      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
      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

              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
            data within a session.  My scenario 2 concerns itself with how
            distinct sessions can be established/maintained.  I suggested
            don't define a way for the producer to describe its grouping
            Rather a consumer can choose to support grouping (via a
      mechanism its
            free to define) or leave it up to the consumer to handle
            (via perference/configuration data).  So in my scenario 2, a
            isn't responsible for separating the portlets into different
            sessions.  It merely is allowed to do so.  Portlets must assume
            aren't running in such environments -- rather they must assume
            run in a shared session world -- hence they need an ID to do
            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
            configuration/personalization UI that allows a group key to be
            specified for each of its portlets -- it can then use this
            group id to key/separate data in the shared session.

            Just a long way of saying -- I don't buy your scenario 2.  If
            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
            portlet A, B, B' in the same session/group -- B and B' can keep
            data separate).  If the consumer doesn't know the grouping then
            controls things just like scenario 1.  The producer is free to
            define/manage finer granularity as described above.

            Eilon Reshef wrote:
                   Mike,Per your recent e-mails, I think that the approach
                  sense.The only thing that concerns me is that we have two

                  different mechanisms to handle what would seem to be a
                  similar scenario.Scenario 1: If there are two occurrences
      of a
                  single portlet on a page, then as you described it the
                  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
                  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
                  segregation keys has the scalability advantage that you
                  mentioned.Can't we use it to handle both
                  scenario 1, where there's portlets A1 and A2, then the
                  sends a key "1" when displaying A1 and a key "2" when
                  displaying A2. In scenario 2, when there's portlet pairs
                  B1> and <A2, B2>, then the portal sends a key "1" when
                  displaying A1 and B1 and the key "2" when displaying A2
                  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
                  draft suggests). The Consumer only has to take into
                  that it may receive (and needs to re-send) a separate
                  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