[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsia] Re: RE: [wsrp] Sessions and Transient Entities
Rex - I think that your diagram visualizes the basic concept according to my understanding. I would only note that the WSRP-session is not initated by the client but by the consumer. In your diagram I got the impression that the client was somewhat involved. 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 07:50 | | | PM | | | 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 | | | | | >---------------------------------------------------------------------------------------------------------------------------------------------| As I was trying to get this process down to the most basic and simple, I diagrammed it using a component diagram. The problem I had with the chart in the 0.1.2 version of the spec is that it read right to left in terms of the flow from the origination of the process with an end user request. I know that this was done because the end point of the process is the end-user but I wasn't able to keep the flow straight in my mind as I read down over the four pages it spans. Also, it covers just about all the variations of flow and types of properties, entities and calls. I found I was better able to use that chart with this diagram in hand. However, I still have problems following Sophisticated to Simple and Simple to Sophisticated within the chart context. Also, it would be helpful to know if what I diagrammed is essentially correct or not, so I attached it. it is a .gif file so you can view it in a web browser or insert it into another program to view it. Thanks, 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> -- -- #### WSIA-WSRP_Joint_Interface.gif has been removed from this note on June 17 2002 by Carsten Leue
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC