[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?
This does not work for "certain" implementations. Implementations will have to seriously think about changing the assumption that consumer is always *the* aggregator to be able to support modern web development techniques. Subbu Richard Jacob wrote: > I think this doesn't work. > - how would the state of the other portets be encoded in the imbedded > portetl URLs? > - how could the other portlets maintain their URLs (containing nav state) > pointing to the "isolated" portlet? > > The proposal would break a lot of things rather than fixing some use cases. > We have to keep in mind that there *is* an aggregator which maintains > states, navigations, etc. > So if you go for an isolated portlet (is it a portlet then at all ;-) ) you > could use resource URLs for that. > > Mit freundlichen Gruessen / best regards, > > Richard Jacob > ______________________________________________________ > IBM Lab Boeblingen, Germany > Dept.8288, WebSphere Portal Server Development > WSRP Team Lead & Technical Lead > WSRP Standardization > Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 > Email: mailto:richard.jacob@de.ibm.com > > > > Subbu Allamaraju > <subbu@bea.com> > To > 01/25/06 07:55 PM 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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]