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



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