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