[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp] Shared Sessions
|---------+----------------------------> | | 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC