Re: [wsrp-comment] Public Comment

[Rich Thompson <richt2@us.ibm.com>]

Michelle, 

Thanks for the feedback on WSRP v2!
The editorial items you noticed are always easier to see when one is newer
to the spec.

On your questions:

1. The point behind the aliases field
is exactly what you are surmising. The key concept behind all of the coordination
mechanisms is that the portlet declares how it can participate in coordination
and the Consumer controls what coordination mechanisms connect which portlets
at runtime. The expectation is that Consumers, such as portals, will expose
the ability to control this information flow to whomever is laying out
a page/application. In general it would not make sense to connect things
which do not share the same semantics, even if the data types match. Of
course, it will be a choice of the Consumer's administration UI as to what
can get mapped to what (i.e. are arbitrary mappings supported). Using QNames
to name each coordination item and any known aliases seeks to provide assistance
in making such semantic matches.

2. Consumer's are encouraged, but not
required, to share items with the same QName which are instantiated within
a single wsrp:consumerSession. The reason for this is that while that is
a good default, there are use cases where it defeats the underlying purpose
(e.g. a page with two instances of the same portlet, configured to show
different information).

3. The way I think of navigation parameters
relative to transient properties is that navigation parameters logically
extend a portlet's navigationalState while transient properties logically
extend the portlet's session (i.e. very different scopes). This allows
the sharing of either type of state without requiring additional manipulation
by portlets.

4. The semantics of how a Consumer could
handle receiving both a redirectURL and events/shared state is so dependent
on the Consumer implementation that we left them mutually exclusive for
v2. The primary use case which would drive a need to define such semantics
depends on extending the semantics of redirectURL. Namely; redirectURL
is currently restricted to being an absolute URL and the protocol currently
provides no means for the portlet being able to redirect to another page
at the Consumer. There is interest in revisiting this during v3 discussions
primarily because of use cases such as the one you cite.

5. Multiple generations of events are
supported by the protocol (required by a number of use cases). Whether
or not to apply an arbitrary limits to event distribution is a question
of Consumer policy (may only support a limited number of generations or
may truncate distribution in order to refresh the page for the user or
...).

6. While all of the metadata about a
portlet could change at runtime, we currently have no mechanism to inform
the Consumer of the change. When this has been discussed within the TC,
it has been pointed out that the emerging WSN standard could provide a
clean solution. WSN just finished its second public review period (with
no comments) and is currently considering when to submit the spec to OASIS
for approval as a standard. Relative to coordination related items, this
implies that the portlet could start generating items the Consumer is not
expecting. There is a potential that the Consumer will simply ignore such
items ... it will likely depend on the Consumer's policy related to "autowiring"
coordination items.

7. Protocol support for portlets implementing
the AJAX interaction pattern is acknowledged as an important use case.
Today portlets can only use resource URLs in the AJAX pattern, but will
also need to deal with the issues of using AJAX in an aggregated environment
(potential for state loss if a different portlet is interacted with, bookmark
issues, etc). The getResource operation introduced in v2 should help such
portlets significantly as this passes all the relevant contextual information
along with the request (rather than relying on cookies over a raw HTTP
request), but still does not allow the coordination activities possible
with action URLs. In addition, the TC is currently discussing whether it
is even feasible to consider additional support in the v2 timeframe as
opposed to deferring it to v3 discussions.

I hope this helps ...

Rich Thompson
OASIS WSRP TC Chair & Specification Editor
IBM T.J. Watson Research Center / Yorktown Heights, NY

comment-form@oasis-open.org

01/31/06 09:01 AM

Please respond to
mo197@doc.ic.ac.uk

To	wsrp-comment@lists.oasis-open.org
cc
Subject	[wsrp-comment] Public Comment

Comment from: mo197@doc.ic.ac.uk

Name: Michelle Osmond
Organization: Imperial College London
Regarding Specification: WSRP v2

Hello,

I've had a look through the WSRP v2 draft 13 and have some comments and
questions on inter-portlet communication and AJAX in portlets. 

I like the flexibility of being able to use both Event/Listener and shared
state for communication between portlets. Could you clarify if:

 - event names and transient property names would not need to match across
different portlets - Portals would allow users to set up connections between
them at page construction time, somehow using the defined 'aliases'. Hopefully
the user could connect events to listening portlets even without matching
names/aliases.

 - "wsrp:consumerSession" scoped properties and events are shared
among all portlets on the Consumer regardless of portlet app/Provider (i.e.
default is cross-context communication)

 - navigation parameters are some kind of alternative to transient properties
for sharing state, possibly something like Oracle's page parameters?


Also, is it correct that these features are not supported:

 - as a result of an Action, cause a page redirect *and* trigger an event
(or transientProperty/navigationalParameter change). I would find this
feature generally useful, e.g. select an item from a List portlet, send
item ID in event, change page to go to the Item Display portlet. (In a
BlockingInteractionResponse, you can have either an updateResponse or a
redirectURL, not both.)

 - a Consumer Configured Portlet changing its own public event interface
(publishedEvents and handledEvents), and its transientPropertyDescriptions,
at runtime.

 - events triggering further events. Although the HandleEventsResponse
Type does include an updateResponse, which might contain more events...
is handleEvents called recursively?

 - automatically invalidate listening portlets' cache in handleEvents (6.2.1.2
says it's to be dealt with in a later spec). This might also need to be
done on changing transient properties/navigation parameters.


I'd love to see support for using AJAX in portlets. (apologies for JSR168
terminology below, I don't know all the WSRP equivalents)

It looks like getResource could be useful - could a servlet resource retrieved
this way read the portlet's own state, e.g. private session variables,
portlet init params/preferences, current user details? This alone would
be very useful, as I think the best we can do at the moment is to access
Application-scope session variables and all other data needs to be passed
in URL/cookies. 
Even better if the servlet could modify that portlet's session (portlet-scope).

I guess there still wouldn't be a way for an XMLHTTP request to trigger
a Blocking Interaction and events/transient property/navigation param changes
before the getMarkup.


Finally, two small things I noticed,
5.1.16, navigationParameterDescriptions has typo
  "to tha same Producer offered portlet handle"
6.1.2, portletInstanceKey sentence is slightly broken
  "to use this key when namespace multiple instances of itself
within Producer supplied mechanisms"

Thanks,

-Michelle

---------------------------------------------------------------------
To unsubscribe, e-mail: wsrp-comment-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsrp-comment-help@lists.oasis-open.org