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