[wsrp][interfaces] 4/25 meeting summary

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

Last weeks agenda and results were:

Agenda:
a) complete last weeks discussion of which operations in the Portal
Usage document we should work on in the first version of the
specification.  I believe we just need to discuss the Portlet Service
Disabled state and Portlet Service upgraded state.

Meeting Summary:

Disabled State: We decided to defer discussing/specifying the
transitions from enabled to disabled states and vice versa.  There is
some question whether this effects the protocol at all as one could
build a system where either the producer/consumer arbitrarily goes into
this state and the opposed component must discover or intuit this state
from its inaccessibility.  Even if there would be an impact on the
protocol it was decided it would be a secondary issue best pushed into a
later version of the specification.

Upgraded state:  We decided this issue should be addressed/covered in
the specification.

b) begin discussing (by answering questions) portlet service
registration.  The questions to be answered/discussed were sent out
yesterday.

Meeting Summary:
We started discussing (by answering posted questions) topics related to
State 0: Service Unknown and State 1: service becomes known.

State 0: Portlet Service Unknown
We identified that the question relating to how a portal locates a
service belongs in this state vs. where it was originally placed in
State 1.

We decided that the specification will not mandate how a portal locates
a service.  We decided that the WSRP group will provide a "best
practices" document (maybe as an addendum to the spec) that details how
UDDI can be used.

We decided that the address of a Portlet Service (for purposes of
binding to it) is the URL to the WSDL service description.

State 1: Portlet Service is activated

1) We discussed the scope of a portlet service.  We decided that a
portlet service is a container of portlets not a portlet itself.  We
decided that the portlets it contains are not services but rather
logical entities that are interacted with through the container (portlet
service).  This leads to the requirement that a portlet can be
identified/targeted within a container.  We did not (as of yet) discuss
how a portlet is identified.

2) Discussed the set of services/function a portlet service expects a
consumer to (be capable) of providing it.  To the list I originally
provided we added: URL rewriting, Authentication, Identity/Profile
information, and View context.

Rather then discuss how these impact the protocol in detail we decided
to move on and address them as they came up in the natural flow of
discussions.

3) Had very preliminary discussion of what a portal/portlet service must
be able to accomplish when a portal activates and registers itself with
a portlet service.  For the first item in the list "establish the portal
vendors identity" we got into a general discussion concerning whether
WSRP should support (vendor) extensibility.  There were two concerns if
we design in extensibility.  The first concern is that it hurts/limits
transportability of portlets.  The second concern is that the extension
mechanism opens the door for vendors creating defacto standards
minimizing the control the WSRP group can exercise over the standard.
On the first issue it was felt that extensions have to be optional.
Portlets must be able to be written without using extensions and run
(adequately) in any environment.  If this is the case then using an
extension is a choice left up to the portlet developer for gaining
preferred behavior in a given environment.  On the second issue, there
was no direct response.  Rather it was offered that supporting
extensions reflects the environment we live in given the many
(differing) portal products that exist.  There was concern that without
extensions WSRP becomes a poor man's portlet API -- one that (at least
until it matures) becomes too low a common denominator for it to achieve
as quick and far reaching success as we would like.  We seemed to agree
that though extensibility is a two edged sword we will support
extensions.