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