Hi,
See my
question inline.
Yossi.
-----Original Message-----
From: Rich Thompson
[mailto:]
Sent: Thursday, August 07, 2003 2:04
PM
To:
Subject: RE:
[wsrp-coord] Should we design in support for out-of band
events?
This discussion
has strayed a long ways from the original question. The question is not about
defining OOB events between WSRP actors ... I think that by definition they
are out-of-band and therefore we can not define them. We may want (at some
future point) to consider whether or not to define communication between the
Consumer and Producer outside of the user-interaction cycle, but that is also
not the question raised.The question is about how do OOB events that WSRP
actors receive impact the defined protocol between the actors.
I think the most common case (#1 below)
is one where the portlet (or the application it is a front for ... the
protocol does not distinguish between these) receives information from an
outside source (e.g. a stock quote portlet receives updated trade
information). I think this is the most trivial case and is likely just a
matter of including any related coordination information in the next
interaction cycle, but I do think that we should keep such scenarios in mind
as we design WSRP coordination.
[Yossi
Tamari] But since the user may never interact with this specific portlet,
and it may not be the recipient of any events, and its markup may be
cached, this portlet may never be called again. So how can we design a robust
mechanism to support this?
Rich Thompson
Andre Kramer
<>
08/06/2003 04:27 AM
To:
cc:
Subject: RE: [wsrp-coord]
Should we design in support for out-of band even
ts?
I would say that coordinating which portlets are involved in
eventing/updates (and which require re-display) is in scope of SC [page /
fragment level invalidation is not].
For out-of-band, we should make sure we
have clear processing phases that can be used to demarcate out of band
signalling. Possibly some sort of virtual clock?
regards,
Andre
-----Original Message-----
From: Tamari, Yossi
[mailto:]
Sent: 06 August 2003
09:04
To:
Subject: RE:
[wsrp-coord] Should we design in support for out-of band even
ts?
Hi Mike,
I am afraid I
didn't get the "Able" joke. You'll have to explain at the F2F...
I think
you just moved from discussing Cross Portlet Coordination to discussing cache
invalidation, which is out of the scope of this committee. The charter of this
committee (if we had one...) is to define coordination between portlets, not
messages from the portlet to the consumer.
While I do not object to defining a set of events a portlet
MAY send that MAY be meaningful to some consumers, I do not think this should
be the focus of this committee, and definitely not to discuss things like
caching.
I am not saying we should preclude WSRP ever supporting OOB events, I
am saying we should take it out of the scope of discussions, and focus on our
deliverable.
What we are doing
in this SC is going to be difficult enough to get everybody to agree to, we
should not even go in the direction of defining extra consumer behaviors
except delivering events/state changes.
Yossi.
-----Original Message-----
From: Michael Freedman
[mailto:]
Sent: Wednesday, August 06,
2003 2:13 AM
To:
Subject:
Re: [wsrp-coord] Should we design in support for out-of band even
ts?
Yossi, should I call you Able? I agree
with Rich that there are producers/portlets which aren't dormant between
consumer requests -- for example portlets fronting syndication servers.
At some point in time we will need to address how these portlets can
communicate changes to its consumer. Piggybacking on the next consumer
request won't always be acceptable. An easy example is an
InvalidateMyContent event -- the above syndication server may need to send an
invalidate event to the consumer when information has been updated so the
consumer knows to rerender the portlet on subsequent requests. If this
type of out-of-band mechanism didn't exist the portlet would have to put a
dummy action in its content [like a refresh me button] just so piggybacking
could occur.
That being said, I think its a medium/low priority
to define out-of-band eventing for 2.0. By this I think we should focus
first on clearlying defining an in-band capability [which I am not yet
convinced is event based]. If we solve this soon enough then we can
tackly out-of-band in 2.0 -- otherwise post 2.0. Though the actual
priority is subject to change depending on how we choose to define
invalidation with respect to events. My second expectation is that
out-of-band eventing [when defined] must be an optional consumer capability.
I.e. portlets will have to deal with running with consumers that don't
provide such a service.
-Mike-
Tamari, Yossi
wrote:
I think the best guidance
we can provide is to ignore this case, implicitly saying that we do not think
it should be used...
I agree
that the _applications_ behind the portlets maybe receiving and sending OOB
events, but I do not think portlets should do that. Portlets have a very clear
life cycle, and in my view when they are not explicitly called by the
container (and consumer) they should be dormant (in a sense they only exist
during the request cycle. Between requests it's just their state that
persists, just like servlets, ASP pages, etc.).
Yossi.
-----Original
Message-----
From: Rich Thompson [mailto:]
Sent: Monday, August 04, 2003 7:28 PM
To:
Subject: Re: [wsrp-coord] Should we design in
support for out-of band events?
This is equivalent to saying that it is up to each implementation
to decide how out-of-band items get reflected into the WSRP interactions. My
gut instinct says this is where we will likely end up, but I think we would do
a disservice to the community-at-large if we don't at least consider the
implications related to out-of-band events and possibly provide some guidance.
Rich Thompson
Alejandro Abdelnur
<>
Sent by:
08/04/2003 11:48 AM
To:
Rich Thompson/Watson/IBM@IBMUS
cc: Alejandro Abdelnur <>,
Subject: Re: [wsrp-coord] Should we
design in support for out-of band events?
I'm not sure we should we care
about out-of-band events, unless we
consider pushing them through WSRP
calls. In other words, making them
in-band.
Alejandro
On
Monday, August 4, 2003, at 06:19 AM, Rich Thompson
wrote:
>
> I think it is important when considering this
question to start with
> the realization that out-of-band events will
occur. We need to
> consider how to reflect these into the interactions
between the WSRP
> actors (Portlet, Producer, Consumer and End-User)
when out-of-band
> communication between at least some of these actors
is not in place.
>
> To consider:
> 1. Portlet/Producer
receives an out-of-band event that may cause a
> change in its
state.
> 2. Consumer receives an out-of-band event (i.e. not a user
> interaction) that it wishes to distribute to various Portlets. Does
> distributing coordination info (events or state) always result in the
> aggregation of markup?
> 3. User-agent receives an event. Is
any communication arising from in
> this case just a virtual
user-interaction (i.e. the other WSRP actors
> view it as a
user-interaction)?
>
> Rich Thompson
