[wsrp][interfaces] Meeting summary 5/16

[Michael Freedman <Michael.Freedman@oracle.com>]

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?