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

[wsrp][interfaces] Summary conference call 5/30

From
Michael Freedman <>
Date
2002-05-30T19:56:59+00:00
ID
Thread
[wsrp][interfaces] Summary conference call 5/30
Attendees:

Mark Cassidy, Netegrity

Rich Thompson, IBM

Alejandro Abdelnur, Sun

Eilon Reshef, WebCollage

Lothar Merk, IBM

Sasha Aickin, Plumtree

Yossi Tamari, SAP Portals

Thomas Schaeck, IBM

Michael Freedman, Oracle

1) Next week's conference call moved to 7:30 am PDT.  Michael Freedman
needs to leave a little after 8:30 to catch a plane.

2) Discussed draft requirements:
We covered the sections concerning location, discovery, and
registration.  We stopped after discussing the first requirement [R17]
in deregistration.

General issue:  Alejandro asked when/how we should discuss
the issue of supporting a portlet configuration model that separates adminsitration/configuration
into a distinct (helper) service.  I indicated we have moved away
from posing questions/discussing topics to focusing on requirements and
specification.  I asked Alejandro to bring up this discussion as appropriate
when we come to the requirements section that pertains or to e-mail the
group and get a discussion going.

Requirements comments:

It was thought useful to make explicit the corollary to R1, namely, A portal
[consumer] need not go through a software intermediary [registry] to locate
a portlet service.

We left Q1 open.  Q1 asks whether and how a portlet service can restrict
the amount of meta data returned to an anonymous consumer.  We deferred
this because we don't yet understand the complete set of meta data to be
returned hence can't anticipate if services might want to restrict information.

As part of discussion for Q1 we identified a new requirement that defines
that a portlet service must return [to anonymous requesters] the minimum
amount of information needed by a consumer to register with it.

On registration, we discussed whether its valid not to require registration
(for services that don't need it).  We decided that allowing a service
to return a null registration handle (and pas on subsequent calls) would
be sufficient.  I.e. its valid to have a no-op registration call. 
New requirements will be added to reflect this.

We discussed Q2 concerning subscription support.  We (tentatively)
decided that this will not be addressed in the first version of the specification.

We deferred Q3 concerning function negotiation until we have more information
concerning what function needs to be negotiated and how that function is
reflected in our protocol.

In discussing R17, a requirement for deregistration, it was suggested/decided
that additional information should be added to clarify the requirement
from the perspective of the consumer.

Need to add a deregistration requirement that says services that return
null from a registration don't expect/require deregister to be called.
← Prev in month ← Prev in thread
Next in thread → Next in month →