[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] WSRP v2 roadmap (was XMLHttpRequest and WSRP 2.0 - wheredo we stand?)
I think we need to discuss/set expectations properly. From my perspective once getting to Committee draft issues/discussions should be limited to the function already designed in the specification. We might have a mechanism for a new feature to come in but the bar should be extremely high -- basically a consensus. My concern with your right up is how you seem to give equal weight to "new use" cases with public review comments and interop issues. I think we shouldn't be setting the expectation that we want to drive new features into 2.0. -Mike- Rich Thompson wrote: > > I went through a number if iterations before proposing the dates I > did. Basically I was trying to balance the need to close down v2 with > the expectation that some issues will be uncovered both during interop > testing and the review periods. My ending point was planning for at > least one iteration dealing with such issues. Of course, this also > leaves open a number of channels by which people will propose new > issues (as opposed to issues with the current v2 content). My view is > that we need to be progressively raising the bar for what new use > cases might be considered for inclusion in v2 so that we can finish > it, but will need to do that in the context of dealing with review > period type comments. > > Rich > > > *Michael Freedman <michael.freedman@oracle.com>* > > 02/08/06 07:16 PM > > > To > Rich Thompson/Watson/IBM@IBMUS > cc > OASIS WSRP TC <wsrp@lists.oasis-open.org> > Subject > Re: [wsrp] WSRP v2 roadmap (was XMLHttpRequest and WSRP 2.0 - where > do we stand?) > > > > > > > > > > I have concerns with this as this seems to anticipate/suggest we will > be expanding the scope of 2.0 during cd-02. I would rather deal with > the question of whether such expanded scope should occur and what it > will look at now then to drag it out. My preference is to not delay > 2.0 but instead plan on a tighter/quicker 3.0. Getting the > coordination features out are important and delay to add other > features isn't warranted at this stage. > -Mike- > > Rich Thompson wrote: > > I propose that we address this by first agreeing on an updated roadmap > for moving v2 to the OASIS std level and then look at addressing this > and any other issues that come up within the framework of that > roadmap. I agree with Richard that planning for interop testing within > the roadmap will improve both the quality of the spec and the > confidence we have in the spec. It also would provides more weight to > the 3+ mandatory statements regarding using the spec. As a result, I > propose the following updated roadmap: > > - Feb 10: Ballot closes approving draft 14 as a Committee Draft > (currently have 3 of the required 8 'yes' votes) > - Feb 16: Approve starting a "TC review" period on cd-01 (i.e. draft > 14); review to run until April 1(I would include other interested > technical groups, such the JSR 286 EG, in this review) > - April 1: Interop testing begins (likely starts with v1 code just > using v2 ports, though hopefully at least some implementations have > the few newly required features in place as well) > - May 18: Approve updated draft as cd-02 and approve a public review > period running until August 1. > - Sept 1: Finish working through any issues identified in the public > review, interop testing or new use cases the TC has agreed to examine. > - Sept 14: Approve updated draft as cd-03 and approve a second public > review period on the changes (15 day -> Oct 1) > - Oct 10: Approve submitting cd-03 to OASIS membership for > consideration as a standard (i.e. make the deadline for submissions on > the 15th). > - Nov 30: WSRP v2 approved as an OASIS std. > > I think this both gets us moving forward on the process of getting v2 > approved and leaves room for the raising of additional use cases and > issues (though I expect getting new use cases to be considered to > become progressively harder). > > If people think this is a reasonable approach, I would suggest we plan > on a TC call near the middle of each month, an Interfaces SC call near > the first of each month and seek to schedule other SC needs on the > remaining Thursday time slots. There may need to be some calls in > other time slots, but we should try and manage placing most calls into > the Thursday slot. > > Rich > > *Subbu Allamaraju **_<subbu@bea.com>_* <mailto:subbu@bea.com> > > 02/02/06 12:08 PM > > > To > OASIS WSRP TC _<wsrp@lists.oasis-open.org>_ > <mailto:wsrp@lists.oasis-open.org> > cc > > Subject > Re: [wsrp] XMLHttpRequest and WSRP 2.0 - where do we stand? > > > > > > > > > > > > I agree that this problem needs to be tackled some day or other, and > IMO, the best way to decide this is to formally discuss this within the > TC and proceed from there. Even if we decide to defer this to V3 at the > end, it is still good to have a common understanding on what the > protocol can accomplish and what it cannot. That would give a clear > indication to developers of how to deal with their use cases and > extend/work-around as necessary. > > Subbu > > Richard Jacob wrote: > > In general I agree that the AJAX use cases are quite important. > > I'm not sure if we really can come up with a solution that quickly > that it > > could make it into V2. > > The options I see is either to not discuss it in the V2 timeframe or to > > delay the spec in terms of going through the OASIS standardization > process. > > We could stablize the spec (approve committee draft, run through company > > internal review and probably even through the public review) and > then add > > an interop period like we did for 1.0. > > This might delay the spec by let's say 3-4 months from the current > > schedule. > > It would give us the opportunity to start implementaton, interop > test and > > get confidence in the spec. > > Furthermore we would also be able to receive the JSR286 EG comments > which > > could be intergrated into V2 and allow us even better allignment. > > > > I guess if we don't want to extend the schedule, we won't be able to > find a > > confident answer to the AJAX questions you raised for V2. > > > > 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>_ <mailto:subbu@bea.com> > > > > To > > 01/26/06 06:24 PM OASIS WSRP TC > > > _<wsrp@lists.oasis-open.org>_ > <mailto:wsrp@lists.oasis-open.org> > > > cc > > > > > > 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>_ <mailto:subbu@bea.com>* > >> > >> 01/25/06 01:55 PM > >> > >> > >> To > >> OASIS WSRP TC _<wsrp@lists.oasis-open.org>_ > <mailto: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>_ <mailto:subbu@bea.com>* > >> > > >> > 01/25/06 12:09 PM > >> > > >> > > >> > To > >> > OASIS WSRP TC _<wsrp@lists.oasis-open.org>_ > <mailto: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>_ <mailto:subbu@bea.com>* > >> > > > >> > > 01/24/06 12:58 PM > >> > > > >> > > > >> > > To > >> > > OASIS WSRP TC _<wsrp@lists.oasis-open.org>_ > <mailto: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_ > > > > > > --------------------------------------------------------------------- > > 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]