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

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

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.