Comments by Carsten
Leue in blue
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?
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:
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?
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)? 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?
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? Is there a way to support both styles
transparently to the producer? How do we support hardcoded/(absolute?) URLs?
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).
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?