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

[Subbu Allamaraju <subbu@bea.com>]

I'll be happy to discuss this further within the TC, but I don't think 
the proposal to add a param is partial. There are some details to be 
clarified in the spec on the semantics and update any implicit 
assumptions about aggregation. I will look into this further this week, 
and post to the TC.

I propose to discuss this during the next interfaces call.

Subbu

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