[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp] Shared Sessions
Carsten, Let me clarify my position. I believe that a consumer can choose to provide a capability for segmenting portlets from the same producer into different sessions. A consumer defines the scope of the session. It is reasonable for a consumer to provide a capability that allows a subset of portlets to be grouped into distinct sessions. But I don't believe that we should mandate that all consumers do so. Nor should we define required meta-data that allows a producer to describe its rules for grouping and have any expectation that a consumer will honor it. A producer that requires a certain segmentation will have to define that segmentation within itself and establish/maintain that segmentation without the help of the consumer. So to be clear: I don't believe that a consumer is restricted to running all portlets/entities in the same session. I do believe that we shouldn't define a way for a portlet/entity to describe how it should be grouped and require consumers adhere to it. Rather, producers must code within themselves to achieve this. -Mike- Carsten Leue wrote: > |---------+----------------------------> > | | Carsten Leue | > | | | > | | 06/06/2002 05:50 | > | | PM | > | | | > |---------+----------------------------> > >---------------------------------------------------------------------------------------------------------------------------------------------| > | | > | To: Michael.Freedman@oracle.com | > | cc: wsrp-interfaces@lists.oasis-open.org | > | From: Carsten Leue/Germany/IBM@IBMDE | > | Subject: Shared Sessions | > | | > | | > >---------------------------------------------------------------------------------------------------------------------------------------------| > > Mike - unfortunately I missed your note that the telephone conference began > earlier. But when we then talked about shared sessions I was a little > concerned. > As far as I understood the proposition, you would vote for creating one > session for ALL remote portlets (coming from one provider). These can then > share data in this session but would be responsible for using namespaces > when trying to store private data. > > This is clearly a simple approach but it recalls me of the "old" > programming models on desktop machines where all processes could access > (and destroy) data from all other processes on a machine. This easily leads > to instability and security issues. > > I would propose that the consumer would be responsible for a sort of > "application protection" where it lets only selected portlets (maybe based > on metadata) share a session. This could efficiently isolate different > logical sets of remote portlets. The argument that in such a case you could > simply create a new portlet service does not hold for me as in may cases > all portlets would be published by the same portal (so the same portlet > service). > > Best regards > Carsten Leue > > ------- > Dr. Carsten Leue > Dept.8288, IBM Laboratory Böblingen , Germany > Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 > > ---------------------------------------------------------------- > 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