Re: [wsrp] WSRP v2 roadmap (was XMLHttpRequest and WSRP 2.0 - where do westand?)

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

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>

02/02/06 12:08 PM

To	OASIS WSRP TC <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>
                     
                     
  
>                    
                     
                     
        To 
>              01/26/06 06:24 PM
        OASIS WSRP TC          
            
>                    
                   <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>*
>>
>> 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
> 
> 
> ---------------------------------------------------------------------
> 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