[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp][interfaces] Meeting summary 5/16
The meeting discussed our concept of instance handles. We defined the following: a) A portlet generates instance handles. b) An instance handle represents a unique persistent reference to a portlet. c) A portal controls when instance handles come into existence d) Instances can be created based on prior instances. Such instances inherit the current characteristics of the "copied" instance. We didn't resolve/complete discussing: a) Can instance creation be implicitly requested by the portal? If so how is this implicit request reflected in the protocol? Background: If the portal is in control of instance creation (so it can impose its semantics) how do we intend to manage the interplay between it and the portlet when a portlet operation should result in a new instance? For example, how does the following work? A portlet renders its own customize screen but a portal wants to ensure a new "instance" is created the first time a user customizes the portlet. Do we require the portal render/own the "submit" button so it can determine when the action occurs? Or do we pass information in the customize request to the portlet so it can determine if it should create a new instance? b) Do we need to support cascading operations? If so for which operations? Background: Since we are supporting a notion of creating new instances based on existing instances will portals use this to model hierarchical groups of portlets that they will want/need to support cascading operations on? For example, a portal on shared pages might have a notion of the default/standard portlet instance that is used for all users that haven't explicitly customized it. Each user customization would be a new instance derived from this initial one. A portal might want to have an efficient mechanism for copying this group of instances (say if the portal supports a copy page function) or deleting this group (say if a user with the default designer role deletes the instance). Two mechanisms were described for handling this: Have the protocol support cascading operations. Have the protocol support bulk operations. In the first, the protocol would accept a single instance reference and the operation would cascade to all its children. In the later, the protocol would accept a list of instances references and the operation would enumerate over each. The main plus raised for cascading operations was the terseness in which the request can be represented. The minuses included making portlet development more complicated because cascading operations require the portlet maintain the hierarchical relationship and awkwardness/inability to return new instances (mappings) on a cascading copy. The pluses/minus for bulk operations are the reverse. c) Finally, we discussed whether we required instance handles be scoped to the entity that created them (the portal). Unfortunately, I can't find my notes for this discussion (They are at home). I believe we said that we wouldn't make this a requirement. Rather, I think we said that this "enforcement" should be doable via our security model. Can someone refresh my memory?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC