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

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

Another Interfaces SC call wasn't scheduled
because we had no open issues and my sense is that people want v2 to be
closing down. 

I think supporting portlets using the
AJAX pattern is an important use case. Like we have done with other use
cases, we should explore the nuances of the use case and the implications
of proposed solutions before we select a means to provide such support.
I think the key question is whether people want to hold v2 until we have
at least an initial pass on such discussions. Considering the direction
the TC gave me relative to draft 14 on the last call, I think it appropriate
to have the default answer to this question be "No" and that
people who want to answer it "Yes" need to do so by an email
post to this thread.

Rich

Subbu Allamaraju <subbu@bea.com>

01/25/06 01:55 PM

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

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


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