RE: [wsrp-coord] Should we design in support for out-of band even ts?

[Andre Kramer <andre.kramer@eu.citrix.com>]

Title:

No polling! All events would carry a virtual clock (single value for consumer and possibly an array of long-int values for each producer involved) that relates the event to previous ones. This allows one event (say an in-band one) to be ordered wrt another (say an out-of-band one) without forcing extra synchronizations. However, we would need to agree such a virtual clock is valuable for real examples. But it's one way to link in-band (synchronous) to other out-of-band events.

 

regards,

Andre

-----Original Message-----
From: Tamari, Yossi [mailto:yossi.tamari@sap.com]
Sent: 06 August 2003 10:39
To: wsrp-coord@lists.oasis-open.org
Subject: RE: [wsrp-coord] Should we design in support for out-of band even ts?

See inline.

   

    Yossi,

-----Original Message-----
From: Andre Kramer [mailto:andre.kramer@eu.citrix.com]
Sent: Wednesday, August 06, 2003 11:27 AM
To: wsrp-coord@lists.oasis-open.org
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:yossi.tamari@sap.com]
Sent: 06 August 2003 09:04
To: wsrp-coord@lists.oasis-open.org
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:Michael.Freedman@oracle.com]
Sent: Wednesday, August 06, 2003 2:13 AM
To: wsrp-coord@lists.oasis-open.org
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:richt2@us.ibm.com]
Sent: Monday, August 04, 2003 7:28 PM
To: wsrp-coord@lists.oasis-open.org
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 <Alejandro.Abdelnur@Sun.COM> Sent by: Alejandro.Abdelnur@Sun.COM 08/04/2003 11:48 AM

To:        Rich Thompson/Watson/IBM@IBMUS         cc:        Alejandro Abdelnur <Alejandro.Abdelnur@Sun.COM>, wsrp-coord@lists.oasis-open.org         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