← Prev in month ← Prev in thread
Next in thread → Next in month →

[wsrp][interfaces] 4/11 Concall summary

From
Michael Freedman <>
Date
2002-04-17T22:33:12+00:00
ID
Thread
[wsrp][interfaces] 4/11 Concall summary
The agenda for this meeting was to make a pass through the portal usage
document written during the prior week and discuss which operations
described in the usage should be the focus of our [future] discussion.

This is a short summary of what we decided.  More detailed notes are
appended thanks to Susan Levine.

1) Decided to refer to the Bind operation as Register
2) Decided that portlet templates will likely need to be addressed in
the initial specification but that it isn't a basic concept.  Hence will
lower its priority to address after the core is covered.
3) In the portlet template's section we decided to:  add an operation
for rendering the settings screen, and that you can get the settings
from the service.
4) We decided to defer the "migration" operations to a future revision
of the specification and for now allow vendor specific solutions.
5) We clarified the statement "You can upgrade a portlet template to a
new version." by adding the following wordings:  "You can upgrade a
portlet template to a new version of the portlet service".  We also
moved this operation into the "upgrade state".
6) We decided that cloning is a second order priority that can/should be
addressed once the core is in good shape.
7) We decided that converting a portlet instance into a portlet template
was an operation for future specification.
8) Clarified the portlet instance render operations to be
portal-centric.  For example, rather then saying "You can request a
portlet instance render its portlet content", we now say "Portal renders
portlet content".
9) We clarified that the number/types of renditions/screens is not
defined by the specification.  I.e. it is open.
10) We added a get personalization data operation to the portlet
instance.
11) We renamed offline/online to disable/enable for clarity.
12) We asked that more discussion/detail be given to "actions" and
"events" before deciding if they belong in our initial specification.
13) We deferred until the next meeting (because time ran out) discussing
operations relating to enabling/disabling a service and upgrading a
service.
14) All other operations are to be discussed/included in the
specification.

Next steps:
I am putting together a questions document to help frame the discussions
that need to occur to get us to the point of defining specific
operational requirements.

     -Mike-
← Prev in month ← Prev in thread
Next in thread → Next in month →