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



Right - especially we should not force the producer to implement a
sophisticated namespace management by letting the consumer manage multiple
sessions that shield the producers' data.


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 02:39 |
|         |           AM               |
|         |           Please respond to|
|         |           Rex Brooks       |
|         |                            |
|---------+---------------------------->
  >---------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                             |
  |       To:       Eilon Reshef <eilon.reshef@webcollage.com>, wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org                            |
  |       cc:                                                                                                                                   |
  |       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