[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp][interfaces and protocols]: Agenda for 4/11
Mike - my comments are included.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory Böblingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+----------------------------->
| | Michael Freedman |
| | <Michael.Freedman@|
| | oracle.com> |
| | |
| | 04/11/2002 01:00 |
| | AM |
| | Please respond to |
| | Michael Freedman |
| | |
|---------+----------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: WSRP <wsrp@lists.oasis-open.org> |
| cc: |
| Subject: [wsrp][interfaces and protocols]: Agenda for 4/11 |
| |
| |
>---------------------------------------------------------------------------------------------------------------------------------------------|
Folks,
For Thursday conference call I would like to go over the operations I
identified in the e-mail I sent last Saturday and classify each by
answering the following two questions:
Axis 1: Is this a valid Portal operation that may need to interact via
WSRP with a portlet?
Yes, we all agree this a valid operation
No, we all agree this is not a valid operation
Maybe, there is debate whether this is a valid operation.
Don't know, we need more information and discussion to understand the
operation before classifying it.
Axis 2: Should this operation be covered/enabled by our spec?
Yes, we all agree.
Yes, but it should be addressed in a later revision.
No, we all agree.
Maybe, there is debate whether we should address this.
Don't know, we need more information to decide.
During the call there will be opportunities to request clarifications as
well as introduce new (unidentified) operations. To facilitate the meeting
could each of you make your own pass over the list and mark each with how
you would answer the 2 questions?
Here is the list:
State 0: Portlet Service Unknown
You can bind to a service (see State 1).
<cl> yes </cl>
State 1: Portlet Service becomes known
Portlet Service Operations:
Acquire portlet meta data
Bind
establish portal identify
establish trust relationship
negotiate behavior
<cl> yes </cl>
Create portlet (template) instance
<cl> yes for the instance - from my opinion the templates should be
on top of WSRP, not in the base protocol </cl>
State 2: Portlet Service Active
Portlet template operations:
You can use a portlet template to create a portlet instance.
The portlet template defines the initial settings of the
portlet instance.
You can modify the portlet template's settings to change its
default/defined behavior.
You can copy a portlet template. By copy it is meant that a
second portlet template comes into being (within the toolbox)
with its settings being a duplicate of the template it was
copied from (vs. the initial default settings defined by the
portlet service).
You can delete the portlet template.
You can migrate a portlet template. By migrate it is meant
that controlling portal can transfer the portlet template to
another portal.
You can upgrade a portlet template to a new version.
<cl> no - templates should be on top of WSRP </cl>
Portlet instance operations:
You can modify the portlet instance's settings to personalize
its behavior. 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.
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.
You can clone a portlet instance. By close it is meant that a
second portlet instance comes into being with its
personalization data being shared with the portlet it was
cloned from.
You can convert a portlet instance into a portlet template.
<cl> no </cl>
You can migrate a portlet instance. By migrate it is meant
that controlling portal can transfer the portlet instance to
another portal.
<cl> what's the difference to cloning </cl>
You can upgrade a portlet instance to a new version.
<cl> why would this be necessary? the service is already remote and
could update itself </cl>
You can delete a portlet instance.
You can request a portlet instance render its portlet content.
You can request a portlet instance render a link reference to
itself.
<cl> is this necessary? </cl>
You can request a portlet instance render help information.
You can request a portlet instance render "about" information.
You can request a portlet instance render its personalization
screen.
You can perform "actions" on a portlet instance. [Mike -- this
is a placeholder until I understand better what folks
want/expect actions to be and do]
You can send an event to a portlet instance.
<cl> we need to work out the difference between events and actions
and should concentrate on one concept for the base WSRP functionality
</cl>
Portlet service operations:
You can request a service be taken offline.
<cl> maybe </cl>
State 3: Portlet Service Inactive
Portlet service operations:
You can request a service come back online.
<cl> maybe </cl>
Random state: Portlet Service upgraded
Portlet service operations
Acquire (new) meta data
(re)negotiate behavior
<cl> maybe </cl>
The conference call details are the same as last week:
US toll free: 877-302-8255
Outside US: +1 303-928-2609
Conference ID: 8814427
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC