Re: [wsrp] XMLHttpRequest and WSRP 2.0 - where do we stand?

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

What would be gained by such a partial
solution that the portlet couldn't simply manage itself (perhaps with Producer
assistance) by using resource URLs and a queue of pending updates within
a session? 

If the long-term solution is clear (i.e.
just needs the details worked out) and the partial solution brings a high
value, then I could see including the partial solution in v2. Otherwise
I would favor leaving the discussion to v3.

Of course, another option would be to
delay v2 until a relatively complete solution is designed ... 

Rich

Subbu Allamaraju <subbu@bea.com>

01/25/06 12:09 PM

To	OASIS WSRP TC <wsrp@lists.oasis-open.org>
cc
Subject	Re: [wsrp] XMLHttpRequest and WSRP 2.0 - where do we stand?

Thanks for your comments.

As some of you might have noticed, there is a LOT of interest in the web
developer community in leveraging Ajax-style technologies. The key issue
with WSRP (and also the Portlet API in the Java-land) is that the 
protocol prevents use of Ajax-style technologies in portlets. A few 
people in the community have tried using XMLHttpRequest with WSRP and 
the Portlet API, but could not make much progress.

Taking one step at a time, the first and the key issue is guaranteeing
that a given render/action/resource URL would cause a consumer-driven 
invocation and rendering of a single portlet.

Here is a proposal. A new URL parameter, let us call it 
"wsrp-aggregate", with a value of "false", would let
portlets create 
URLs that are guaranteed to cause a single portlet invocation.

For example, to create an interaction URL to post some data via 
XMLHttpRequest, a portlet would create a URL with wsrp-aggregate=false.

The consumer will then invoke the phases of the portlet's lifecycle 
(pbia, he, and getMarkup). Depending on how the consumer implements 
support for events, it would either process events for all portlets on
the page, or store the events for later processing, or simply discard 
events targeted for other portlets. Note that the current event model 
makes no assumptions about page aggregation.

IMO, other problems (see comments below) related to supporting 
Ajax-style interactions are implementation specific. The key issue for
WSRP is to support such interactions within the protocol. Given the 
popularity and interest in using Ajax in web apps, we should consider 
taking the first steps towards supporting such interactions in V2, and
continue further work in V3 based on implementation experience.

Regards,
Subbu


Rich Thompson wrote:
> 
> 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

Right, and that was my motivation for bringing up this topic. Some of 
the problems like page refresh and back buttons are fundamental to Ajax
style of interactions. As you may be aware, W3C Web API WG is looking 
into these.

> 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

Right. The consumer will have to be smart enough to manage state such 
that it is not lost due to a simple page refresh. A hard problem for the
consumer to solve, but not impossible. Given the strong interest in Ajax
among web developers, consumers will have to start considering these 
problems.

> 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.

I don't know Ajax-style interactions open new security issues. I think
the security issues are more fundamental.

> 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.

I agree. Consumers wanting to fully support such interactions will have
to find better ways to implement event coordination. Consumers can no 
longer assume that all portlets participating in an event train are 
being rendered in an aggregated page. Similar issues arise if a consumer
is implemented using iframes.

> #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.
> 
> Rich
> 
> 
> *Subbu Allamaraju <subbu@bea.com>*
> 
> 01/24/06 12:58 PM
> 
>                  
> To
>                  OASIS
WSRP TC <wsrp@lists.oasis-open.org>
> cc
>                  
> Subject
>                  [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
> xml/markup.
> 
> 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.
> 
> Regards,
> Subbu
> 
> ---------------------------------------------------------------------
> 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
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> ---------------------------------------------------------------------
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 at: 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


---------------------------------------------------------------------
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
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php