[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