OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [wsrp-comment] Public Comment


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


01/31/06 09:01 AM
Please respond to

[wsrp-comment] Public Comment

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

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


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 ( 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"



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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]