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