OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [wsrp][security] Agenda for 5/1 telecon: User Profile

> I'd like to focus discussion in tomorrow's call on the issue of user
> profile.  There seems to be different ideas about what personalization
> means and how it relates to user profile.  
> Take the runtime flow of a portlet computing the markup it returns to the
> portal:  the portlet requires a number of parameters to be defined in
> order to generate the markup it returns to the portal.  Some of these
> parameters may be explicitly associated with the portlet instance and
> stored with the persistent data for that instance.  Other parameters may
> be obtained from someplace else, such as user profile, where that data may
> be shared by other portlets or used for other functions within the portal.
> Another twist to this is that it is not uncommon for portals to support
> the notion of a portlet parameter value which is scoped to a group.  
> The logic that drives assembling all the parameters needed by a portlet to
> generate it's markup needs to be clear.   
> A couple questions to get some discussion going on the forum prior to the
> meeting:
> 1.  Should a portlet instance be scoped to individual users, with all
> parameters fully specified, such that a given instance always returns the
> same markup?  Or should an instance represent a partial parameterization
> of a portlet service(one step more fully specified than the portlet
> template), where the remainder of user-specific parameter values needed
> are fetched at runtime from some source outside the portlet instance?
> Another scenario might be that *all* users' parameterizations would be
> maintained with the instance data; in this case, the runtime invocation
> would require both an instance handle and some type of user handle.  My
> own opinion on this is that each instance should correspond to a fully
> enumerated parameter set, where a unique instance handle would exist for
> each user's personalized configuration of the portlet.   
> 2.  If not all the parameter values are stored with the instance, what
> mechanisms should be supported for assembling the full parameter set at
> runtime?  How is this divided between portal and portlet?  A user profile
> would logically fall under this mechanism. 
> I'm going to be offsite for the remainder of the day today and will be
> back on email later tonight to followup on any discussion around these
> points.
> Logistics:
> Time:  Wednesday, 5/1;  8:00 a.m. PST(11:00 a.m. EST, 6:00 p.m. CET)
> U.S. Phone:   877.450.3529
> International phone:  +1.706.679.6653 
> Conference Code: 4254672722

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC