[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
Does the spec allow this? This could complicate the Producer-mediated
sharing...
=20
Aretm
=20
________________________________
From: Rich Thompson [mailto:richt2@us.ibm.com]=20
Sent: Wednesday, March 09, 2005 4:53 PM
To: wsrp@lists.oasis-open.org
Subject: RE: [wsrp] spec-2.0-draft-05: events and blocking actions
=20
There hasn't been an agreement on blocking semantics yet. I would be
against any semantics beyond requiring all event distribution (Note that
a Consumer could consider a Portlet which hasn't responded in a timely
manner to have finished, but failed to return a response) to end before
starting the getMarkup step.=20
To see why network and load issues matter, consider a Consumer
distributing events to two different portlets ... the order in which
they return events is likely to vary from one invocation to the next.=20
Rich=20
"Spector, Artem" <artem.spector@sap.com>=20
03/09/05 09:33 AM=20
To
<wsrp@lists.oasis-open.org>=20
cc
=20
Subject
RE: [wsrp] spec-2.0-draft-05: events and blocking actions
=20
=20
=20
But if we say that event distribution is blocking (we almost agreed on
it, didn't we? :-)), then the event order will be well-defined and will
not depend on network etc.=20
=20
Artem=20
=20
=20
________________________________
From: Rich Thompson [mailto:richt2@us.ibm.com]=20
Sent: Wednesday, March 09, 2005 3:41 PM
To: wsrp@lists.oasis-open.org
Subject: RE: [wsrp] spec-2.0-draft-05: events and blocking actions=20
=20
I would note that multiple portlets couldn't depend on events between
them being ordered even outside the Consumer's option to reorder the
events it delivers due to network and varying workload effects on the
different Producers.=20
Rich=20
"Yossi Tamari" <yossi@giloventures.com>=20
03/09/05 04:05 AM=20
=20
To
"Stefan Hepper" <sthepper@hursley.ibm.com>=20
cc
<wsrp@lists.oasis-open.org>=20
Subject
RE: [wsrp] spec-2.0-draft-05: events and blocking actions
=20
=20
=20
=20
I think the reason we required the portlet to return the events in order
was to allow a consumer that wanted to distribute the events in order,
to do so.
I do think this is a meaningful capability, and I don't really think it
makes the portlet logic more difficult (remember that the portlet gets
to decide what is the correct order), it just tell implementations "use
a vector and not a set".
I do think there should be at least guidance in the spec, for consumers,
that if they do not have a reason to change the order of the events,
they should attempt to keep it. It seems to me that developing a
multiple portlet/multiple events application without being able to
assume event ordering will be nearly impossible. (In reality my guess
would be that every event would contain in its internal data some sort
of timestamp, so that the receiving portlet will be able to manage
dropping older events).
Yossi.
-----Original Message-----
From: Stefan Hepper [mailto:sthepper@hursley.ibm.com]=20
Sent: Wednesday, March 09, 2005 9:30 AM
To: Yossi Tamari
Cc: wsrp@lists.oasis-open.org
Subject: Re: [wsrp] spec-2.0-draft-05: events and blocking actions
When reading the spec draft I also was wondering why the event=20
processing order is not defined. The event processing oder may influence
the outcome of the eventing. I don't understand why the event array=20
needs to be ordered when the event execution on the consumer is=20
unspecified. What was the reason for requiring the events be in sequence
in the event array?
For example is it possible to have the following sequence:
P1 returns events e1, e2
e1 is distributed to P2
P2 returns events e3, e4
e3 is distributed to P1
e4 is distributed to P3
e2 is distributed to P3
P3 now gets an older event as the last event even as e4 may be the more=20
accurate data. I understand that events are not guaranteed to be=20
delivered, so P3 may never have gotten e4. However, I think it makes the
portlet logic a bit more complex and it should be stated explicitly in=20
the spec that no order is guaranteed.
Stefan
Yossi Tamari wrote:
> Two comment bellow, marked with <YT>.
>=20
> =20
>=20
> Yossi.
>=20
> =20
>=20
>
------------------------------------------------------------------------
>=20
> *From:* Rich Thompson [mailto:richt2@us.ibm.com]
> *Sent:* Tuesday, March 08, 2005 8:49 PM
> *To:* wsrp@lists.oasis-open.org
> *Subject:* RE: [wsrp] spec-2.0-draft-05: events and blocking actions
>=20
> =20
>=20
>=20
> Comments in-line
>=20
> Rich
>=20
> *"Spector, Artem" <artem.spector@sap.com>*
>=20
> 03/08/05 12:59 PM
>=20
> =20
>=20
> To
>=20
> =20
>=20
> <wsrp@lists.oasis-open.org>
>=20
> cc
>=20
> =20
>=20
> =20
>=20
> Subject
>=20
> =20
>=20
> RE: [wsrp] spec-2.0-draft-05: events and blocking actions
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> =20
>=20
>=20
>=20
>=20
> Some more thoughts about event handling:
>=20
> 1. Separate between event generations. If a Consumer
during
> distribution of some events (current generation) gets a response with
a
> new portion of events (new generation), it must finish distribution of
> the current generation events before starting distribution of the next
> generation events.
>=20
> <rdt>Why would this Consumer implementation choice be any more valid=20
> than a choice to queue pending events for each portlet and send them=20
> whenever a portlet is not actively processing events? In particular,
why=20
> should the messaging protocol (WSRP) select what is a valid=20
> implementation choice for either of its endpoints (as opposed to=20
> defining the semantics of the message flow)? In the case of=20
> handleEvents, the semantics are the Consumer passing a set of events
it=20
> chose to distribute to the Portlet. I think how the Consumer made the=20
> choice to distribute these particular events or chose to order the=20
> events should remain a Consumer choice.</rdt>
>=20
> <YT>I think leaving the order to be the consumer is under-specifying.=20
> Let's say that during the portlet's run, it generated two events=20
> "Lakers" and "Pistons". We require the portlet to return them in the=20
> correct order (in section 6.4.2.1), but we don't specify that the=20
> consumer need to send these events to another portlet in the correct=20
> order, which means whether it will display Lakers or Pistons is=20
> completely random.
>=20
> I think the order SHOULD be kept by the consumer, or at least we need
to=20
> make such a recommendation. Of course, we are not even requiring the=20
> consumer to propagate the events, so there is no place for a MUST
here.=20
> This does not necessarily imply the concept of generations, which is a
> simplification of the ordering requirement.</YT> =20
>=20
>=20
>=20
> 2. What to do when handleEvent() returns redirectUrl?=20
> Should the
> Consumer redirect immediately, or should it finish the event
> distribution first? What if different Portlets handling the same event
> return different redirectUrls?
> Or may be the Consumer should ignore the redirectUrls of the event
> handling, and respect only the result of the blocking action which has
> triggered the event chain?
>=20
> <rdt> Consensus from previous discussions have been to leave this up
to=20
> Consumer policy. Spec should probably explicitly state this.</rdt>
>=20
> 3. The optimization when a Portlet sends markup in the
> UpdateResponse seems a bit problematic, because the same Portlet may
be
> invoked several times within the same "three-step" loop generating
each
> time a different markup...
>=20
> <rdt>Remember that each time a Portlet returns markup, it is saying
this=20
> markup reflects its current state. Unless the Portlet changes its=20
> navState, mode or ..., the previously returned markup may be fetched=20
> from a cache.</rdt>
>=20
> Considering all these complications I would propose to redesign the
> HandleEventResponse so that it will include neither redirectUrl, nor
> Events. This would make the event handling flow more simple and
> consistent.
> As for the "cascading multi-generation events" (which will not be
> supported in this case), they have so many side effects that could
> easily cause unpredictable behavior.
>=20
> <rdt>But they are also essential for a number of use cases. The only=20
> problems I have seen to-date with multiple generations is when people=20
> try to make this loosely-coupled model exhibit tightly-coupled=20
> behavior.</rdt>
> <YT>I agree, but like some of the other questions raised recently
around=20
> these topics, these are things that took us some serious discussions
to=20
> realize. I think we need to add more wordage to the spec to explain
the=20
> reasoning behind the decisions, and the expected use patterns.
Otherwise=20
> we are going to get the same questions from everybody who reads the
spec=20
> and was not part of the discussions...</YT>
>=20
>=20
> Regards,
> Artem
>=20
> -----Original Message-----
> From: Subbu Allamaraju [mailto:subbu@bea.com]
> Sent: Monday, March 07, 2005 7:29 PM
> To: wsrp@lists.oasis-open.org
> Subject: Re: [wsrp] spec-2.0-draft-05: events and blocking actions
>=20
> Some more comments below.
>=20
> Subbu
>=20
>=20
>> From the Producer point of view, handling the user interactions and
> the
>> events are very similar tasks. The spec describes an interaction as
an
>=20
>> "encodable event" (6.4.2), which points out that interactions and
> events
>> are just two different ways to invoke the same Portlet logic.
>> This idea however is not expressed strongly in the spec, which
causes
>> some confusion. Below is a list of questions:
>> =20
>> 1. HandleEventResponse and BlockingInteractionResponse are
>> identical, but defined as two distinct types, why is this?
>>
>> <rdt>Opened issue #43</rdt>
>=20
> I thought we discussed this during last F2F, but I don't recollect
what
> the resolution was.
>=20
>> 2. According to paragraph 6.4.2.1 Event Handling, the
Consumer
>> may invoke handleEvent() on different Portlets simultaneously. But
if
>> the event handling has the same Producer-side semantics as
processing
>> user interaction, all the restrictions described in paragraph 6.4.1
> must
>> be applicable as well. Which means that all the operations on the
page
>=20
>> must be blocked until handleEvent() either returns or fails.
>>
>> <rdt>My understanding from the discussion to-date is that
handleEvent
>> invocations may happen in parallel, but that other processing is
> blocked
>> until the Consumer decides it has no more events for a particular
>> portlet. The Consumer may then start a getMarkup on that portlet.
I'm
>> sure we need to be more explicit about this ... do people think that
> the
>> Consumer must wait for all portlets to exit the event distribution
> step
>> before starting to collect markup? </rdt>
>=20
> I agree that we need to be explicit. Semantically, it would be
> consistent to specify that event distribution is blocking.
>=20
>> 3. What if HandleEventResponse contains events? Must they be
>> processed by the Consumer?
>> Let's consider a Consumer processing a page which contains two
> portlets:
>> P1 and P2.
>> a. Consumer calls P1.performBlockingInteraction(), and gets
> event E1
>> b. Consumer propagates the event to the Portlets:
>> i.
>> Question: should the consumer invoke P1.handleEvent(E1)? I guess
> no...
>> <rdt>The Consumer is not bound to send the event to any portlets and
I
>=20
>> expect most will explicitly exclude the source portlet. Should we
make
>=20
>> this explicit in the spec so that portlets design for it?</rdt>
>=20
> It is perfectly valid for P1 to subcribe for E1. I don't see any
reason
> to exclude this possibility.
> ii.
>> Consumer calls P2.handleEvent(E1) and gets another event E2 in the
>> response.
>> iii. =20
>> Must the Consumer call P1.handleEvent(E2)? If yes, there could be
an
>> endless loop; if no, the HandleEventResponse should not contain
> events...
>> <rdt>The Consumer is free to exit the event distribution step
whenever
>=20
>> it wants to. As part of loop prevention, Consumers should have a
limit
>=20
>> on the number of generations of events they distribute ...</rdt>
>> =20
>> Regards,
>> Artem
>> *Artem Spector* | Portal Platform Infrastructure | NetWeaver
> Application
>> Platform | SAP Labs Israel| (+972-9) 7779567
>> =20
>=20
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsrp-help@lists.oasis-open.org
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsrp-help@lists.oasis-open.org
>=20
---------------------------------------------------------------------
To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsrp-help@lists.oasis-open.org
------_=_NextPart_001_01C524BA.8F295D2B
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40";>
<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:sans-serif;
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:#606420;
text-decoration:underline;}
p
{mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=3DEN-US link=3Dblue vlink=3D"#606420">
<div class=3DSection1>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>My point is that the blocking =
semantics of
handleEvent() should be the same as of =
performBlockingAction().<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>From this point of view allowing a
Consumer to distribute events to two different Portlets simultaneously =
is same
as allowing the Consumer to invoke blockingAction on two different =
Portlets simultaneously
(for example as a result of a User clicking on two portlets on the =
page). <o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Does the spec allow this? This =
could
complicate the Producer-mediated =
sharing…<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Aretm<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<div>
<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>
<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>
</span></font></div>
<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Rich =
Thompson
[mailto:richt2@us.ibm.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, March =
09, 2005
4:53 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
wsrp@lists.oasis-open.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [wsrp]
spec-2.0-draft-05: events and blocking =
actions</span></font><o:p></o:p></p>
</div>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'><br>
</span></font><font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;
font-family:sans-serif'>There hasn't been an agreement on blocking =
semantics
yet. I would be against any semantics beyond requiring all event =
distribution
(Note that a Consumer could consider a Portlet which hasn't responded in =
a
timely manner to have finished, but failed to return a response) to end =
before
starting the getMarkup step.</span></font> <br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>To
see why network and load issues matter, consider a Consumer distributing =
events
to two different portlets ... the order in which they return events is =
likely
to vary from one invocation to the next.</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'><br>
Rich </span></font><br>
<br>
<o:p></o:p></p>
<table class=3DMsoNormalTable border=3D0 cellpadding=3D0 width=3D"100%"
style=3D'width:100.0%'>
<tr>
<td width=3D"40%" valign=3Dtop style=3D'width:40.0%;padding:.75pt =
.75pt .75pt .75pt'>
<p class=3DMsoNormal><b><font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:
7.5pt;font-family:sans-serif;font-weight:bold'>"Spector, =
Artem"
<artem.spector@sap.com></span></font></b><font size=3D1 =
face=3Dsans-serif><span
style=3D'font-size:7.5pt;font-family:sans-serif'> =
</span></font><o:p></o:p></p>
<p><font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:
sans-serif'>03/09/05 09:33 AM</span></font> <o:p></o:p></p>
</td>
<td width=3D"59%" valign=3Dtop style=3D'width:59.0%;padding:.75pt =
.75pt .75pt .75pt'>
<table class=3DMsoNormalTable border=3D0 cellpadding=3D0 =
width=3D"100%"
style=3D'width:100.0%'>
<tr>
<td style=3D'padding:.75pt .75pt .75pt .75pt'>
<p class=3DMsoNormal align=3Dright style=3D'text-align:right'><font =
size=3D1
face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:sans-serif'>To</span></font><o:p></o=
:p></p>
</td>
<td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
<p class=3DMsoNormal><font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:
=
7.5pt;font-family:sans-serif'><wsrp@lists.oasis-open.org></span></f=
ont>
<o:p></o:p></p>
</td>
</tr>
<tr>
<td style=3D'padding:.75pt .75pt .75pt .75pt'>
<p class=3DMsoNormal align=3Dright style=3D'text-align:right'><font =
size=3D1
face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:sans-serif'>cc</span></font><o:p></o=
:p></p>
</td>
<td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p> </o:p></span></font></p>
</td>
</tr>
<tr>
<td style=3D'padding:.75pt .75pt .75pt .75pt'>
<p class=3DMsoNormal align=3Dright style=3D'text-align:right'><font =
size=3D1
face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:sans-serif'>Subject</span></font><o:=
p></o:p></p>
</td>
<td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
<p class=3DMsoNormal><font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:
7.5pt;font-family:sans-serif'>RE: [wsrp] spec-2.0-draft-05: events =
and
blocking actions</span></font><o:p></o:p></p>
</td>
</tr>
</table>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p> </o:p></span></font></p>
<table class=3DMsoNormalTable border=3D0 cellpadding=3D0>
<tr>
<td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p> </o:p></span></font></p>
</td>
<td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p> </o:p></span></font></p>
</td>
</tr>
</table>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p></o:p></span></font></p>
</td>
</tr>
</table>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><br>
<br>
<br>
</span></font><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:navy'>But if we say that event distribution is =
blocking
(we almost agreed on it, didn’t we? </span></font><font size=3D2
color=3Dnavy face=3DWingdings><span =
style=3D'font-size:10.0pt;font-family:Wingdings;
color:navy'>J</span></font><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>), then the =
event order
will be well-defined and will not depend on network etc.</span></font> =
<br>
<font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
Arial;color:navy'> </span></font> <br>
<font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
Arial;color:navy'>Artem</span></font> <br>
<font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
Arial;color:navy'> </span></font> <o:p></o:p></p>
<p class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'><o:p> </o:p></span></font></p>
<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>
<hr size=3D2 width=3D"100%" align=3Dcenter>
</span></font></div>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><br>
</span></font><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Rich =
Thompson
[mailto:richt2@us.ibm.com] <b><span style=3D'font-weight:bold'><br>
Sent:</span></b> Wednesday, March 09, 2005 3:41 PM<b><span =
style=3D'font-weight:
bold'><br>
To:</span></b> wsrp@lists.oasis-open.org<b><span =
style=3D'font-weight:bold'><br>
Subject:</span></b> RE: [wsrp] spec-2.0-draft-05: events and blocking =
actions</span></font>
<br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'><br>
I would note that multiple portlets couldn't depend on events between =
them
being ordered even outside the Consumer's option to reorder the events =
it
delivers due to network and varying workload effects on the different =
Producers.</span></font>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'><br>
<br>
Rich </span></font><o:p></o:p></p>
<table class=3DMsoNormalTable border=3D0 cellpadding=3D0 width=3D"100%"
style=3D'width:100.0%'>
<tr>
<td width=3D"43%" valign=3Dtop style=3D'width:43.0%;padding:.75pt =
.75pt .75pt .75pt'>
<p class=3DMsoNormal><b><font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:
7.5pt;font-family:sans-serif;font-weight:bold'>"Yossi =
Tamari"
<yossi@giloventures.com></span></font></b><font size=3D1 =
face=3Dsans-serif><span
style=3D'font-size:7.5pt;font-family:sans-serif'> =
</span></font><o:p></o:p></p>
<p><font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:
sans-serif'>03/09/05 04:05 AM</span></font> <o:p></o:p></p>
</td>
<td width=3D"56%" valign=3Dtop style=3D'width:56.0%;padding:.75pt =
.75pt .75pt .75pt'>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p> </o:p></span></font></p>
<table class=3DMsoNormalTable border=3D0 cellpadding=3D0 =
width=3D"100%"
style=3D'width:100.0%'>
<tr>
<td width=3D"12%" style=3D'width:12.0%;padding:.75pt .75pt .75pt =
.75pt'>
<p class=3DMsoNormal align=3Dright style=3D'text-align:right'><font =
size=3D1
face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:sans-serif'>To</span></font><o:p></o=
:p></p>
</td>
<td width=3D"87%" valign=3Dtop style=3D'width:87.0%;padding:.75pt =
.75pt .75pt .75pt'>
<p class=3DMsoNormal><font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:
7.5pt;font-family:sans-serif'>"Stefan Hepper"
<sthepper@hursley.ibm.com></span></font> <o:p></o:p></p>
</td>
</tr>
<tr>
<td style=3D'padding:.75pt .75pt .75pt .75pt'>
<p class=3DMsoNormal align=3Dright style=3D'text-align:right'><font =
size=3D1
face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:sans-serif'>cc</span></font><o:p></o=
:p></p>
</td>
<td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
<p class=3DMsoNormal><font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:
=
7.5pt;font-family:sans-serif'><wsrp@lists.oasis-open.org></span></f=
ont>
<o:p></o:p></p>
</td>
</tr>
<tr>
<td style=3D'padding:.75pt .75pt .75pt .75pt'>
<p class=3DMsoNormal align=3Dright style=3D'text-align:right'><font =
size=3D1
face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:sans-serif'>Subject</span></font><o:=
p></o:p></p>
</td>
<td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
<p class=3DMsoNormal><font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:
7.5pt;font-family:sans-serif'>RE: [wsrp] spec-2.0-draft-05: events =
and
blocking actions</span></font><o:p></o:p></p>
</td>
</tr>
</table>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><br>
<o:p></o:p></span></font></p>
<p><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'><o:p> </o:p></span></font></p>
<table class=3DMsoNormalTable border=3D0 cellpadding=3D0 =
width=3D"100%"
style=3D'width:100.0%'>
<tr>
<td width=3D"50%" valign=3Dtop style=3D'width:50.0%;padding:.75pt =
.75pt .75pt .75pt'>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'> <o:p></o:p></span></font></p>
</td>
<td width=3D"49%" valign=3Dtop style=3D'width:49.0%;padding:.75pt =
.75pt .75pt .75pt'>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'> <o:p></o:p></span></font></p>
</td>
</tr>
</table>
<p><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'><o:p></o:p></span></font></p>
</td>
</tr>
</table>
<p style=3D'margin-bottom:12.0pt'><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><br>
<br>
<br>
</span></font><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><br>
I think the reason we required the portlet to return the events in =
order<br>
was to allow a consumer that wanted to distribute the events in =
order,<br>
to do so.<br>
I do think this is a meaningful capability, and I don't really think =
it<br>
makes the portlet logic more difficult (remember that the portlet =
gets<br>
to decide what is the correct order), it just tell implementations =
"use<br>
a vector and not a set".<br>
I do think there should be at least guidance in the spec, for =
consumers,<br>
that if they do not have a reason to change the order of the events,<br>
they should attempt to keep it. It seems to me that developing a<br>
multiple portlet/multiple events application without being able to<br>
assume event ordering will be nearly impossible. (In reality my =
guess<br>
would be that every event would contain in its internal data some =
sort<br>
of timestamp, so that the receiving portlet will be able to manage<br>
dropping older events).<br>
<br>
Yossi.<br>
<br>
-----Original Message-----<br>
From: Stefan Hepper [mailto:sthepper@hursley.ibm.com] <br>
Sent: Wednesday, March 09, 2005 9:30 AM<br>
To: Yossi Tamari<br>
Cc: wsrp@lists.oasis-open.org<br>
Subject: Re: [wsrp] spec-2.0-draft-05: events and blocking actions<br>
<br>
When reading the spec draft I also was wondering why the event <br>
processing order is not defined. The event processing oder may =
influence<br>
<br>
the outcome of the eventing. I don't understand why the event array <br>
needs to be ordered when the event execution on the consumer is <br>
unspecified. What was the reason for requiring the events be in =
sequence<br>
<br>
in the event array?<br>
<br>
For example is it possible to have the following sequence:<br>
<br>
P1 returns events e1, e2<br>
e1 is distributed to P2<br>
P2 returns events e3, e4<br>
e3 is distributed to P1<br>
e4 is distributed to P3<br>
e2 is distributed to P3<br>
<br>
P3 now gets an older event as the last event even as e4 may be the more =
<br>
accurate data. I understand that events are not guaranteed to be <br>
delivered, so P3 may never have gotten e4. However, I think it makes =
the<br>
<br>
portlet logic a bit more complex and it should be stated explicitly in =
<br>
the spec that no order is guaranteed.<br>
<br>
Stefan<br>
<br>
<br>
Yossi Tamari wrote:<br>
> Two comment bellow, marked with <YT>.<br>
> <br>
> <br>
> <br>
> Yossi.<br>
> <br>
> <br>
> <br>
><br>
------------------------------------------------------------------------<=
br>
> <br>
> *From:* Rich Thompson [mailto:richt2@us.ibm.com]<br>
> *Sent:* Tuesday, March 08, 2005 8:49 PM<br>
> *To:* wsrp@lists.oasis-open.org<br>
> *Subject:* RE: [wsrp] spec-2.0-draft-05: events and blocking =
actions<br>
> <br>
> <br>
> <br>
> <br>
> Comments in-line<br>
> <br>
> Rich<br>
> <br>
> *"Spector, Artem" <artem.spector@sap.com>*<br>
> <br>
> 03/08/05 12:59 PM<br>
> <br>
> <br>
> <br>
> To<br>
> <br>
> <br>
> <br>
> <wsrp@lists.oasis-open.org><br>
> <br>
> cc<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> Subject<br>
> <br>
> <br>
> <br>
> RE: [wsrp] spec-2.0-draft-05: events and blocking actions<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> Some more thoughts about event handling:<br>
> <br>
> 1. Separate
between event generations. If a Consumer<br>
during<br>
> distribution of some events (current generation) gets a response =
with<br>
a<br>
> new portion of events (new generation), it must finish distribution =
of<br>
> the current generation events before starting distribution of the =
next<br>
> generation events.<br>
> <br>
> <rdt>Why would this Consumer implementation choice be any =
more valid
<br>
> than a choice to queue pending events for each portlet and send =
them <br>
> whenever a portlet is not actively processing events? In =
particular,<br>
why <br>
> should the messaging protocol (WSRP) select what is a valid <br>
> implementation choice for either of its endpoints (as opposed to =
<br>
> defining the semantics of the message flow)? In the case of <br>
> handleEvents, the semantics are the Consumer passing a set of =
events<br>
it <br>
> chose to distribute to the Portlet. I think how the Consumer made =
the <br>
> choice to distribute these particular events or chose to order the =
<br>
> events should remain a Consumer choice.</rdt><br>
> <br>
> <YT>I think leaving the order to be the consumer is
under-specifying. <br>
> Let's say that during the portlet's run, it generated two events =
<br>
> "Lakers" and "Pistons". We require the portlet =
to
return them in the <br>
> correct order (in section 6.4.2.1), but we don't specify that the =
<br>
> consumer need to send these events to another portlet in the =
correct <br>
> order, which means whether it will display Lakers or Pistons is =
<br>
> completely random.<br>
> <br>
> I think the order SHOULD be kept by the consumer, or at least we =
need<br>
to <br>
> make such a recommendation. Of course, we are not even requiring =
the <br>
> consumer to propagate the events, so there is no place for a =
MUST<br>
here. <br>
> This does not necessarily imply the concept of generations, which =
is a<br>
<br>
> simplification of the ordering requirement.</YT> <br>
> <br>
> <br>
> <br>
> 2. What to =
do when
handleEvent() returns redirectUrl? <br>
> Should the<br>
> Consumer redirect immediately, or should it finish the event<br>
> distribution first? What if different Portlets handling the same =
event<br>
> return different redirectUrls?<br>
> Or may be the Consumer should ignore the redirectUrls of the =
event<br>
> handling, and respect only the result of the blocking action which =
has<br>
> triggered the event chain?<br>
> <br>
> <rdt> Consensus from previous discussions have been to leave =
this up<br>
to <br>
> Consumer policy. Spec should probably explicitly state =
this.</rdt><br>
> <br>
> 3. The
optimization when a Portlet sends markup in the<br>
> UpdateResponse seems a bit problematic, because the same Portlet =
may<br>
be<br>
> invoked several times within the same "three-step" loop
generating<br>
each<br>
> time a different markup...<br>
> <br>
> <rdt>Remember that each time a Portlet returns markup, it is =
saying<br>
this <br>
> markup reflects its current state. Unless the Portlet changes its =
<br>
> navState, mode or ..., the previously returned markup may be =
fetched <br>
> from a cache.</rdt><br>
> <br>
> Considering all these complications I would propose to redesign =
the<br>
> HandleEventResponse so that it will include neither redirectUrl, =
nor<br>
> Events. This would make the event handling flow more simple and<br>
> consistent.<br>
> As for the "cascading multi-generation events" (which =
will not
be<br>
> supported in this case), they have so many side effects that =
could<br>
> easily cause unpredictable behavior.<br>
> <br>
> <rdt>But they are also essential for a number of use cases. =
The only
<br>
> problems I have seen to-date with multiple generations is when =
people <br>
> try to make this loosely-coupled model exhibit tightly-coupled <br>
> behavior.</rdt><br>
> <YT>I agree, but like some of the other questions raised =
recently<br>
around <br>
> these topics, these are things that took us some serious =
discussions<br>
to <br>
> realize. I think we need to add more wordage to the spec to =
explain<br>
the <br>
> reasoning behind the decisions, and the expected use patterns.<br>
Otherwise <br>
> we are going to get the same questions from everybody who reads =
the<br>
spec <br>
> and was not part of the discussions...</YT><br>
> <br>
> <br>
> Regards,<br>
> Artem<br>
> <br>
> -----Original Message-----<br>
> From: Subbu Allamaraju [mailto:subbu@bea.com]<br>
> Sent: Monday, March 07, 2005 7:29 PM<br>
> To: wsrp@lists.oasis-open.org<br>
> Subject: Re: [wsrp] spec-2.0-draft-05: events and blocking =
actions<br>
> <br>
> Some more comments below.<br>
> <br>
> Subbu<br>
> <br>
> <br>
>> From the Producer point of view, handling the user =
interactions
and<br>
> the<br>
>> events are very similar tasks. The spec describes an =
interaction
as<br>
an<br>
> <br>
>> "encodable event" (6.4.2), which points out =
that
interactions and<br>
> events<br>
>> are just two different ways to invoke the same Portlet =
logic.<br>
>> This idea however is not expressed strongly in the spec, =
which<br>
causes<br>
>> some confusion. Below is a list of questions:<br>
>> <br>
>> 1. HandleEventResponse and
BlockingInteractionResponse are<br>
>> identical, but defined as two distinct types, why is =
this?<br>
>><br>
>> <rdt>Opened issue #43</rdt><br>
> <br>
> I thought we discussed this during last F2F, but I don't =
recollect<br>
what<br>
> the resolution was.<br>
> <br>
>> 2. According to paragraph =
6.4.2.1
Event Handling, the<br>
Consumer<br>
>> may invoke handleEvent() on different Portlets =
simultaneously.
But<br>
if<br>
>> the event handling has the same Producer-side semantics =
as<br>
processing<br>
>> user interaction, all the restrictions described in =
paragraph
6.4.1<br>
> must<br>
>> be applicable as well. Which means that all the =
operations on
the<br>
page<br>
> <br>
>> must be blocked until handleEvent() either returns or =
fails.<br>
>><br>
>> <rdt>My understanding from the discussion to-date =
is that<br>
handleEvent<br>
>> invocations may happen in parallel, but that other =
processing is<br>
> blocked<br>
>> until the Consumer decides it has no more events for a
particular<br>
>> portlet. The Consumer may then start a getMarkup on that
portlet.<br>
I'm<br>
>> sure we need to be more explicit about this ... do people =
think
that<br>
> the<br>
>> Consumer must wait for all portlets to exit the event
distribution<br>
> step<br>
>> before starting to collect markup? </rdt><br>
> <br>
> I agree that we need to be explicit. Semantically, it would be<br>
> consistent to specify that event distribution is blocking.<br>
> <br>
>> 3. What if HandleEventResponse
contains events? Must they be<br>
>> processed by the Consumer?<br>
>> Let's consider a Consumer processing a page which =
contains two<br>
> portlets:<br>
>> P1 and P2.<br>
>> a. Consumer calls
P1.performBlockingInteraction(), and gets<br>
> event E1<br>
>> b. Consumer propagates the =
event to
the Portlets:<br>
>> =
=
=
i.<br>
<br>
>> Question: should the consumer invoke P1.handleEvent(E1)? =
I
guess<br>
> no...<br>
>> <rdt>The Consumer is not bound to send the event to =
any
portlets and<br>
I<br>
> <br>
>> expect most will explicitly exclude the source portlet. =
Should
we<br>
make<br>
> <br>
>> this explicit in the spec so that portlets design for
it?</rdt><br>
> <br>
> It is perfectly valid for P1 to subcribe for E1. I don't see =
any<br>
reason<br>
> to exclude this possibility.<br>
> =
=
=
ii.<br>
>> Consumer calls P2.handleEvent(E1) and gets another event =
E2 in
the<br>
>> response.<br>
>> =
=
=
iii.
<br>
>> Must the Consumer call P1.handleEvent(E2)? If yes, there =
could
be<br>
an<br>
>> endless loop; if no, the HandleEventResponse should not =
contain<br>
> events...<br>
>> <rdt>The Consumer is free to exit the event =
distribution
step<br>
whenever<br>
> <br>
>> it wants to. As part of loop prevention, Consumers should =
have a<br>
limit<br>
> <br>
>> on the number of generations of events they distribute
...</rdt><br>
>> <br>
>> Regards,<br>
>> Artem<br>
>> *Artem Spector* | Portal Platform Infrastructure | =
NetWeaver<br>
> Application<br>
>> Platform | SAP Labs Israel| (+972-9) 7779567<br>
>> <br>
> <br>
> <br>
> <br>
> =
---------------------------------------------------------------------<br>=
> To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org<br>
> For additional commands, e-mail: wsrp-help@lists.oasis-open.org<br>
> <br>
> <br>
> =
---------------------------------------------------------------------<br>=
> To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org<br>
> For additional commands, e-mail: wsrp-help@lists.oasis-open.org<br>
> <br>
<br>
<br>
<br>
<br>
<br>
---------------------------------------------------------------------<br>=
To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org<br>
For additional commands, e-mail: =
wsrp-help@lists.oasis-open.org</span></font><o:p></o:p></p>
</div>
</body>
</html>
------_=_NextPart_001_01C524BA.8F295D2B--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]