[wsrp][interfaces and protocols]: First concall

["MICHAEL.FREEDMAN" <MICHAEL.FREEDMAN@oracle.com>]

Folks,
    Our first concall for the Interfaces and Protocols subcomittee
meeting is Thursday April 4th at 8am PST, 11am EST, 6pm CET and 1 am in
Japan.  Note:  I believe Europe switches to daylight saving time this
weekend.  The US switches next weekend.  Hence Germany is 10 hours 
ahead of US west coast time next week.

Conference call details:
     In the US: 877-302-8255
     Outside US: +1 303-928-2609

When you dial in you will be asked for a "conference id".

The conference id is:  8814427

This is a permanent id.  It will be used for all subsequent conference
calls.

I propose the following agenda for the conference call on April 4th:
1) Identify someone to take/publish call minutes. (Note: it would 
really be helpful if someone volunteered before the 4th so we can
merely do introductions and move on.  Any takers?  Anyone willing
to do at least a month rotation?)

2) Identify discussion topics and set priorities.
I propose our first call concern itself with breaking the area into a
set of discrete discussion topics, identifying the basic/initial
questions that need to addressed in these areas, and setting an order
for discussion.  The later is intended to lay out on order for follow 
on conference calls.  Hopefully, e-mail discussions in all topical
areas will proceed in parallel.

Does this seem reasonable for a first conference call?  Are there
additional/different things we should talk about?

To preseed the discussion on Thursday I have attached a document with a
list of possible topic categories and series of questions to
answer that I culled from the various discussions from last week.  If
possible please send me your ideas/comments before Thursday so I can 
update the preliminary agenda/document.

      -Mike-

Title: InterfacesProtocols

Discussion Areas

 
• SOAP encoding

How do we return marked up content in a soap response?  efficiently?
Should we support an escape hatch so the getContent request can be made via HTTP post?
Are there any performance numbers we would like the implementation team to generate for us to better understand how to most efficiently use SOAP?
 
• WSIA

I am assuming for the moment that the areas where WSIA/WSRP overlap will NOT be discussed in this subcommittee -- the pupose of this ietm is to define explicitly what is exlcuded.  From my notes taken at last week's meeting this would seem to be:
• activation/deactivation
• version detection/expression

 
• WSRP interfaces
• Instance lifecycle
• create -- What are the things we want a producer to be able to do when a portlet instance is created?  What information is needed from the consumer to do this?  Who controls/creates the instance handle (portlet id)?
• destroy -- What are the things we want a producer to be able to do when a portlet instance is deleted?
• other operations -- Are there other operations we should consider?  Do we need to define a copy method?  How about a publish method (when a portal is being moved from a dev to a stage to a production environment)?  Others?
• Content generation

What information does the producer need to generate content?  How does the producer know what content to produce?  How does the producer return content?  How does it indicate content type and encoding?  Should we start with an assumption that most renderers adhere to the HTTP get/post response model and try and map from that to SOAP?
• Actions

What are actions?  How are they different from events? Why are they needed?  Do actions produce content?  Can action handlers cause other actions or events to be triggered? If so how does a portlet instance discover and identify targets? How can actions be efficiently implemented?
• Events/messaging

What are events?  How are they different from actions?  Why are they needed?  Do events produce content? Can event handlers cause other actions or events to be triggered?  If so how does a portlet instance discover and identify targets?  Are events a general purpose concept that should utilize a general purpose messaging system or is the messaging system defined and managed by the consumer/Portal? How can events be efficiently implemented?
• Session Management/Portlet Grouping

What are session for; maintaining state within a single portlet and/or maintaining between a set of (cooperating) portlets?  If the later, do we need a notion of a Portal application/group/provider int he API?  If we do, what is its role (from an API/abstraction perspective)?  How are sessions established?  By the consumer? By the consumer requesting a session? Or willy-nilly in responses by the producer (this is the http/servlet model)?  Who can invalidate a session?  How does each side get notified? How does a consumer react when told a session has become invalid?  How does the portlet/producer?
• Request data

What information should the portal pass to the portlets when requesting markup?
 
• Order of method invocation, client, & server contracts

I don't have any specific questions to throw out here -- to a certain extent this probably falls out of answering the questions in the other topic areas.  Anyone have any ideas?
 
• URL Rewriting

Does the consumer or a producer do URL rewriting?  (Note: If the producer then URL rewriting is used loosely here as no rewriting might take place if URLs are written correctly in the first place)  What are the factors we need to consider to make a decision?  Performance? Ease of use?  Correctness?  Is there a way to support both styles transparently to the producer? How do we support hardcoded/(absolute?) URLs?
 
• namespace encoding

How does the portal/portlets distinguish portlet instance form/request parameters such that each instance can (safely) locate its parameters in the request?  If namespace/prefixing is used, what is a name composed of? Does the portal expose only a portlet instance's parameters to the instance or does the instance "see" other request parameters?  If parameters are isolated how is this implemented?
 
• Remote portlet vs remote portlet container

Does the API we are designing generally require a producer side runtime (portlet container) to make it convenient for content developers?  If so, should WSRP define a least one more API, a simple API, that removes/hides the extra complexity of the full version?