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] XMLHttpRequest and WSRP 2.0 - where we stand?

While I would agree that supporting portlets which use AJAX-style communications is an important use case, I think a full discussion of the issues will not happen quickly. Some of the issues I see are:

1. While data oriented communications are reasonably supported via resource URLs, interactions that impact portlet state cause problems, such as:
 - inability to clone the portlet if enduring state changes
 - inability to communicate an updated navState back to the Consumer (consider what happens if the page updates due to a user interaction with a non-AJAX enabled portlet)
 - inability to leverage the new shared state models

2. Portlet state cached in the browser. Key point here is that the browser becomes part of the overall processing done by the portlet. Any state held within the browser can easily be lost; consider, for example, the impacts of a page refresh

3. Insufficient browser security model. This is already an issue with composed pages (i.e. malicious portlet can activate an action link from a different portlet) though the user would get a reasonable notification by the page refreshing. If such a malicious portlet could also suppress the notification to the user, this problem becomes severe.

4. Coordination impacts. In order to preserve the concept of the page reacting as a whole to user interactions, AJAX-style actions really should use the full 3-steps of the protocol with the modification that only the impacted portlets are rerendered. I think this drives the model toward Consumer-control over such partial updates rather than asking the sourcing portlet to update multiple places on the page.

#4 makes me think this ought to leverage the Consumer resource model, which has been deferred to v3. If others agree, perhaps this can be the early focus in the v3 discussions with the new ExtensionDescription mechanism leveraged to apply whatever is defined back into v2.


Subbu Allamaraju <subbu@bea.com>

01/24/06 12:58 PM

OASIS WSRP TC <wsrp@lists.oasis-open.org>
[wsrp] XMLHttpRequest and WSRP 2.0 - where we stand?

I have been investigating various use cases that developers are trying
to solve by using XMLHttpRequest in their applications, and how WSRP
stacks up against those use cases. I do find some limitations in the
protocol that make it hard to solve some use cases. I would like to find
out what people think.

Most of the use cases that rely on XMLHttpRequest can be grouped into
two categories:

a. Downloading data/markup: An example is auto-filling forms based on
what the user entered previously. This is similar to google-suggest.

b. Submitting data: An example is a user login. Upon login, the browser
replaces the login form with another markup fragment. Netflix's movie
rating is another example.

The first use case is idempotent, and URLs to download data/markup can
be created as resource URLs. Now that WSRP 2.0 provides the portlet's
context while fetching resources, developers can let portlets return

The second use case is typically non-idempotent. Portlets may want to
change their state while processing data. In some cases, portlets may be
affecting the state of other portlets either via spec-provided
coordination mechanisms or some producer-managed sharing.

But it turns out that implementing the second use case is very tricky.
Let me jot down the key steps that a portlet might try:

a. Create an action URL in the markup.

b. Submit data to the this URL

c. Update browser to use/render returned data/markup

But these steps don't play well with WSRP. In most implementations, the
generated action URL points to an aggregated page which causes a pbia,
zero or more handleEvents, and one or more getMarkup calls.

In the current use case, the portlet needs a URL that is guaranteed to
cause a pbia for the targeted portlet, and return markup for the same
portlet. That is, the consumer must not return an aggregated page for
this to work.

The difficulty is that the protocol does not provide a way to create
such an interaction URL. The nature of the URL is completely up to
implementations. Implementations cannot solve it either since portlets
may be creating normal interaction URLs and these special portlet-only
URLs in the same markup fragment and producers/consumers can't
distinguish between these two.

Currently, developers can work-around this use case only via resource
URLs. But resource URLs don't permit state changes, and so limit the
ability of portlets to handle the use case completely.

I'm seeking comments from this group on how important these use cases
are for your implementations, and have any thoughts on supporting these
use cases.


To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS

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