Title:
See
inline.
Yossi,
-----Original Message-----
From: Andre Kramer
[mailto:]
Sent: Wednesday, August 06, 2003
11:27 AM
To:
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].
[Yossi Tamari] I agree that the spec should
enable portlets that received events to send new markup. I think this
should be managed much like an interaction. I do not think we should develop a
special cache invalidation mechanism for
eventing.
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?
[Yossi
Tamari] I would like to see a proposition on how this can work. I
currently fail to see the value of demarcating something that may
have happened a long time ago, and is outside the spec to begin
with.
If this means adding a new stage where
all portlets are polled, I would strongly object. Otherwise, since
portlets are only called after an interaction with them, or an in-band event
they subscribed to (including their state being "written"), this would be
extremely not deterministic, and not
useful.
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
