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

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:]
Sent: 06 August 2003 
  10:39
To: 
Subject: RE: 
  [wsrp-coord] Should we design in support for out-of band even 
  ts?

  
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