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

Title: 

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].

 

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?

 

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