[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][interfaces] Portlet instance handles
> On the surface it seems that portlets need an id that represents a >portal's portlet page instance on a per user basis as a key to that >user's personalization data for that portlet instance. Are there other >needs for this key? If not why do we need to generate such an id if >there is no personalization data or if the personalization is being >managed by the portlet itself (in this case the portlet can choose to >generate its own id and managed the mapping itself)? And even if the >portal is maintaining the personalization data why can't it choose the >key itself? As long as the per-instance personalization is provided for, whether it's done via the personalization being tied to the instance handle or through a level of indirection given some sort of userID that's transferred along with the instance handle, the same end result is accomplished. The key point is that per-instance personalization is required. From a security perspective, I agree with Yossi: there are many content scenarios where user's 'personalize' their view(of a portlet instance) without needing to provide any identifying information about themselves. Seems that any bloat associated with having handles being per-user/per-instance would be proportional to the number of portlet parameters that are shared across users of an instance versus the number of parameters that are personalizable by each user. From my experience, the persistent data managed for individual user personalization is the largest component. Bloat may not be as big an issue given that we have to support per-instance personalizaton in some fashion. -----Original Message----- From: Tamari, Yossi [mailto:yossi.tamari@sapportals.com] Sent: Friday, May 10, 2002 6:31 AM To: 'Michael Freedman '; 'WSRP ' Subject: RE: [wsrp][interfaces] Portlet instance handles Hi Mike, The way I was looking at the handle was as an opaque generated by the portlet and returned to it on consecutive calls by the portal. The portal will probably have its internal handle for each portlet, but this is outside our scope. The idea here is that the portlet CAN generate a different handle for every user, if it manages personalization data, or it can return the same handle for all users. The advantage of this over passing the user id is that the portlet know that this is the same user that requested it before, but it doesn't know WHO this user actually is. This gives the user an added layer of privacy (for portlets that do not require profile or user information). Yossi. -----Original Message----- From: Michael Freedman To: WSRP Sent: 5/9/02 11:47 PM Subject: [wsrp][interfaces] Portlet instance handles Folks, In a number of subcommittees I believe it has been expressed/assumed that: a) Portlet instances have unique persistent ids/handles that will be retained both by the portal and the portlet service. b) A portlet instance (handle) corresponds to a given user of a given portlet on a portal page. c) This handle will be generated by the portlet service. I have been surprised by (b) being part of the assumption and would like to understand better why folks feel this the right way to model things. I am surprised because it seems to require the portal maintain N instance references per portlet on a page where N corresponds to the number of users (who have visited this page). Representing a database company I guess I should be happy that we want this data bloat ;-) Seriously, however, I would like to understand why we think its proper/necessary to manage this persistent id when a more lightweight mechanism exists -- namely one persistent id that represents the portlet instance on the page + the current user identity. Basically, it seems the downside of the assumed/proposed approach are large(r) data sets being maintained in the portal that likely makes export operations, upgrades, etc. more expensive. In addition it requires the portal to runtime map from an obvious key (the page's portlet instance and the user id) to this handle. On the surface it seems that portlets need an id that represents a portal's portlet page instance on a per user basis as a key to that user's personalization data for that portlet instance. Are there other needs for this key? If not why do we need to generate such an id if there is no personalization data or if the personalization is being managed by the portlet itself (in this case the portlet can choose to generate its own id and managed the mapping itself)? And even if the portal is maintaining the personalization data why can't it choose the key itself? -Mike- ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- 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