1>How
does your two terms "Serialized/Stored Instance" and "Active Instance" differ
from the one's in my document; "Personalization Data" and "Portlet
Instance"? They seem very similar to me.
"Portlet
Instance" in your document means - "a portlet on a page; or more generically a
portlet in the portal layout structure". If this means a portlet instance is
created only when viewed by the end user (i.e. runtime and not design
time), then my apologies for failing to understand.
I believe my failure to understand came from the list of
operations you designated on portlet instances. For example "You can copy a
portlet instance. By copy it is meant that a second portlet instance comes
into being with its personalization data being a duplicate of the instance it
was copied from". Why does WSRP need such an operation? Instead (In your
terminology), the portal can just create a new instance with the personalization
data used to create the old instance.
Now, I understand why a portal would need to
expose such functionality to the end user (copy/paste of a portal on the page),
but why would WSRP?
2>Also, why do you think its important/required that portal
store/manage the portlets (producers) settings and personalization data?
Isn't there value in allowing these portlets to store/maintain this data
themselves?
Good question (and very much related to the first!).
This may be true, but remember that a remote portlet may work with
multiple portals (each with a different user base) at the same time. If we
require the portlet to store customization preferences, then this puts too much
burden on portlet. In the "local" portlet world, the portlet had access to
infrastructural code (of the portal) that can store the preferences for the
portlet. This structural code was usually code supplied by the portal. In the
remote portlet world, the portlet is "alone", and must supply "preference"
storage themselves, i.e. a database.
Moreover, this information must be synchronized
with the data stored in the portal itself about the portal instance (for
example, the location of the portal instance on the page). So the two must be
synchronized. But this is difficult - what happens when the user deletes the
portal instance from the page - should the portal send a "deleteData" message to
the portlet? What if the portlet is "down" at that time? Now the portal needs to
queue the request.
Another (more conceptual/logical) problem is that (and I
quote from your document) "There are an arbitrary set of personalization levels
defined by the particular portal. The levels are hierarchical. The
deepest personalization level that has any overriding values controls the user's
view" - do we expect the portlet to understand this hierarchy and the rules
governing the overriding and inheritance? If portlet's store the personalization
data, then they must. And if they must, then WSRP must define the hierarchy and
the rules. Do we expect WSRP to standardize these? Seems to me that this is the
domain of the portals, and not of the interface.
I think these two questions all boil down to the second one: who
manages the personalization/customization data - the portal or the
portlet?
Gil
-----Original Message-----
From: Michael Freedman
[mailto:]
Sent: Tuesday, April 09, 2002
00:23
To: Gil Tayar
Cc:
''
Subject: Re: [wsrp][interfaces and
protocols]: Portal using WSRP Service
Gil,
How does your two terms "Serialized/Stored Instance" and
"Active Instance" differ from the one's in my document; "Personalization Data"
and "Portlet Instance"? They seem very similar to me.
Also, why do you think its important/required that
portal store/manage the portlets (producers) settings and personalization
data? Isn't there value in allowing these portlets to store/maintain
this data themselves?
-Mike-
Gil Tayar wrote:
Hi
Thomas,
<note>
As I was not in the
F2F, and have not yet posted to this mailing list, I would like to introduce
myself. My name is Gil Tayar, I am the Chief Architect of WebCollage, and a
colleague of Eilon Reshef.
</note>
I very much
liked your life-cycle description, and I think it can provide a descent
framework on which to base WSRP's life-cycle and interface/protocol
discussions. It also complements Mike's more detailed document very
well.
To summarize
the states of a portlet, you have the following:
1.
Unbound: The portlet exists, but there is _no_ connection to the
portal.
2. Bound: the portlet is bound, and
registered in the portal.
3. Template: a
portlet template is created by the portal, with a given set of
parameters.
4. Instance: A template inside a given
user page.
As a member
of WSIA, where states #1-#3 do not "exist" (yet!), I would like to dig
deeper into the "Instance state". It seems to me that this state should be
subdivided into two:
4a.
Serialized/Stored Instance: the template and the customizations the
user selected and put in the page, as it exists in the "persistence
store/database" of the portal.
4b. Active
Instance: the entity used to render the portlet and "do the
actions".
I believe the
distinction between the two is an important one, as important as the
distinction between a java object serialized to a stream, and the java
object itself. One (the serialized object or portlet) is "just" data used to
create the other.
To make
another point, the state names I gave are a bit confused. Some are "states"
and some are "entity types". We can deconstruct this
further:
Entity
Types -
1. Portlet. The remote service that
responds to WSRP messages.
2. Bound
Portlet. The location and registration information for the Portlet, as
stored by the portal.
3. Portlet
Template. The set of parameters to be used when creating a Stored
Instance, as stored by the portal.
4. Stored Portlet
Instance. The set of customization options to be used for a certain user
page, as stored by the portal.
5. Active
Instance. The viewed portlet, when viewed inside the
portal.
The above
lists turns the "states" into more of a list of "operations" which create
entities from other entities -
Operations
-
1. Binding: a request of the
administrator(?) to the portal to register the portlet and store location
and registration information, to be used when creating a portlet
template.
2. Creating a Template: Using the
location and registration information, get the meta-data, query the
administrator(?) for the parameters, and store them.
3.
Inserting Template into Page: User selects a template, customizes it,
and creates a Stored Portlet Instance from it.
4.
Viewing the Portlet: User opens portal, and the portal creates an
Active Instance from the Stored Instance.Hope it makes
sense,Gil-----Original Message-----
From: Thomas
Schaeck [mailto:]
Sent: Sunday, April 07, 2002 18:19
To: Michael Freedman;
Subject: Re: [wsrp][interfaces and protocols]: Portal using WSRP
Service
Hi Mike,
here's the life-cycle writeup I promised:
Binding to a WSRP Service
-------------------------
Pre: - The Portal and the WSRP Portlet Service are not
bound -
1. The administrator browses the directory for WSRP
services using the
portal admin UI -->
- The Portal finds the WSRP Portlet Service in the
directory
2. The administrator selects a WSRP service -->
- The Portal makes a call or series of calls to the WSRP
Portlet Service to
establish a relation (bind) (may
include establishing a trust relation, see
my
security note)
- The Portal creates a portlet
template referencing the WSRP portlet
service.
(Potentially, the template may need to be parameterized with
template settings to become usable.)
Post: - The portal is bound to the WSRP service through the
portlet
template, users may now see the template
beeing offered in the portal's
customizer -
Creation of Instances
---------------------
Pre: - The portal is bound to the WSRP service through the
portlet
template, users may now see the template
beeing offered in the portal's
customizer/toolbox
-
3. A portal user selects the portlet template to be put on
a page -->
- The portal server creates a portlet
instance from the portlet template
- The portal
server links the instance to the user's page
Post: - The portal is bound to the WSRP service through the
portlet
template, users may now see the template
beeing offered in the portal's
customizer/toolbox
and a unique instance which may have persistent data now
exists for the user
Destruction of Instances
------------------------
Pre: - The portal is bound to the WSRP service through the
portlet
template, users may now see the template
beeing offered in the portal's
customizer/toolbox
and a unique instance which may have persistent data now
exists for the user
4. A portal user discards a portlet instance from a page
-->
- The portal discards the link from the page
to the instance
- The portal discards the
instance
Pre: - The portal is bound to the WSRP service through the
portlet
template, users may now see the template
beeing offered in the portal's
customizer/toolbox,
the unique instance does no longer exist
Unbinding a WSRP service
------------------------
Pre: - The portal is bound to a WSRP service through a
portlet template,
users may now see the template
beeing offered in the portal's customizer -
5. The adminstrator browses the list of portlet tempplates
and discards the
portlet template -->
- The portal makes a call to the WSRP Portlet Service
referenced in the
portlet template to undo the
binding
- The portal discards the portlet
template
Post: - The Portal and the WSRP Portlet Service are not
bound -
Best regards,
Thomas
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
