[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][interfaces and protocols]: First concall
Title: InterfacesProtocols-----Original Message-----
From: MICHAEL.FREEDMAN [mailto:MICHAEL.FREEDMAN@oracle.com]
Sent: Sunday, March 31, 2002 10:45 AM
To: wsrp@lists.oasis-open.org
Cc: michael.freedman@oracle.com
Subject: [wsrp][interfaces and protocols]: First concallFolks, 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-
Comments by Eilon Reshef in red Comments by
Alan Kropp in fuchsia Comments by Carsten
Leue in blue Discussion Areas
Make
sure that the SOAP flavour used is compatible to
implementations other that J2EE (e.g. .NET)
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: I believe the overlap is likely to cover quite a bit more than the items listed. WSIA Embedded services (of which portlets are considered to be a specific case) in general have lifecycle, security, URL rewriting, etc. concerns. I think the 'overlap' refers to the common mechanisms needed to handle these, and the discussion of these items here is the source of requirements to drive further discussion and specification in the WSIA/WSRP joint interface group.
A
couple of quick thoughts: - There
seem to be different notions of lifecycle and state: one is design-time (when
setting up new portals or portal pages) and one is run-time (when new users
come to a portal page and create specific instances of porlets).
It could be nice to form a terminology around that (e.g., design-time versus
run-time and portlet template versus portlet instance??) .
- A
couple of additional questions related to the design-time model. What workflow
is supported for creating a portlet template? Does the portal need to be “registered”
with the portlet? Any extensibility around the process for
creating and approving creation of a design-time portlet? (E.g., if the portlet owner needs to know about it or approve it?)
Any design-time information the portlet needs to get? Is the persistent data always
stored at the portlet? Also on the portal? - Are
we all under the assumption that the portlet producer will provide an opaque
handle to a portlet template, which can be instantiated in run-time? I wonder if design-time considerations are beyond the scope of WSRP? We're creating a set of specifications that WSRP-compliant portlets must implement, but the process of achieving compliance should be an exercise for further specification.
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? I tend to think maybe it should be the other way 'round. Let's think initially in terms of a general remote access model like SOAP, because we may want to support alternate interactions like multicast, or even one-way, as well as the most common case, request/response.
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? How are actions encoded in the markup?
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? Do we need events in WSRP or can we live with actions for the sake of ease-of-use and ease-of-implementation?
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)? Is the portlet always stateful?
(probably not) 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? Can user-specific run-time data be persistent as well?
(e.g., a “Remember Me” box in a login page) If so, is this part of this
topic or the lifecycle topic? (Might be a good idea to combine the two under “State
Management”)
What information should the portal pass to the portlets when requesting markup? Will all data need to be published with each request or will it be possible to initialize the service once and send only differential data in the subsequent calls?
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?
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? Decoupling between producer and consumer? Robustness? Is there a way to support both styles transparently to the producer? How do we support hardcoded/(absolute?) URLs? URLs created dynamically with scripting (i.e., JavaScript)? URLs encapsulated in some binary content (e.g., links from a Flash file or an applet)? Is there an explicit/implicit notion of URLs that shouldn’t be rewritten?
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? Can the URL rewriting principle be
used to rewrite namespace prefixes? Performance and ease of use need to be considered.
It would be nice if WSRP would allow for services with static content (so
namespace rewriting would be done on the client). Are there any namespace restrictions around content
elements (HTML IDs, JavaScript function names, etc.)? Across
different portlets? Across different instances of the
same portlet?
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC