wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [wsrp][all] First Conference Call on Thursday
- From: Lothar Merk <MERK@de.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Tue, 02 Apr 2002 09:56:14 +0200
Hello,
Michael asked me to use the Oracle Conf-Call number also for the biweekly
Thursday call.
Thus the Call-In Number for our call on Thurseday (April 4) will be
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.
Call-In Time: at 9 am PST / 12 am EST / 7 pm CET
I propose the following Agenda:
- Approval/Comments on Minutes
- Hosting of next Face-to-Face-Meeting
- Revised WSRP Charter
- WSRP Dictionary (Jeff Brobergs Comments)
- Business Scenarions - Templates
- Any Other Business
Attached you can find the Charter with the changes we agreed upon in the
first face-to-face meeting and a template for the business scenarios.
Example business scenario from the WSIA TC can be found under
http://www.oasis-open.org/committees/wsia/scenarios/index.shtml.
Regards, Lothar
(See attached file: wsrp-charter-20020402.doc)(See attached file: WSRP
Business Scenario - Template.doc)
Lothar Merk
IBM Pervasive Computing
E-mail: merk@de.ibm.com, Tel.: ++49-7031-16-4585, Fax.: ++49-7031-16-4888
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Germany
----- Forwarded by Lothar Merk/Germany/IBM on 02.04.2002 08:36 -----
|---------+----------------------------->
| | "MICHAEL.FREEDMAN"|
| | <MICHAEL.FREEDMAN@|
| | oracle.com> |
| | |
| | 31.03.2002 20:44 |
| | Please respond to |
| | "MICHAEL.FREEDMAN"|
| | |
|---------+----------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: wsrp@lists.oasis-open.org |
| cc: michael.freedman@oracle.com |
| Subject: [wsrp][interfaces and protocols]: First concall |
| |
| |
>------------------------------------------------------------------------------------------------------------------------------|
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-
(See attached file: InterfacesProtocols.html)
Attachment:
wsrp-charter-20020402.doc
Description: Binary data
Attachment:
WSRP Business Scenario - Template.doc
Description: Binary data
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?
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC