[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] XMLHttpRequest and WSRP 2.0 - where do we stand?
My answer is YES. Given the importance of the use cases, it would be useful to spend a couple of weeks to see if we have some consensus on the issues/solution(s). Subbu Rich Thompson wrote: > > 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 > > > --------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]