Re: [wsrp-coord] Should we design in support for out-of band events?

Title: 

Exactly.  Though it seems to have caused confusion, this is exactly why I
suggested we will have to [eventually] define OOB events.  Folks seem to
have missed my recomendation however, that this be a low priority for us
at the moment and likely not a 2.0 deliverable so we can focus on the IBE
case.  And I think this my have been missed because I qualified this recommendation
with a unless we decide that InvalidateCache should be represented as an
event as InvalidateCache has all the characteristics that OOB events do.
 So please for the moment forget I ever mentioned InvalidateCache.

    -Mike-

Tamari, Yossi wrote:

 
 
  
   
  
 
  
Hi,

 
  
 

 
  
See my  question inline.

 
  
 

 
  
    Yossi.

 
     
    
-----Original Message-----

    From: Rich Thompson    [mailto:]

    Sent: Thursday, August 07, 2003 2:04    PM

    To: 

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

    

    

    

    This discussion    has strayed a long
ways from the original question. The question is not about    defining OOB
events between WSRP actors ... I think that by definition they    are out-of-band
and therefore we can not define them. We may want (at some    future point)
to consider whether or not to define communication between the    Consumer
and Producer outside of the user-interaction cycle, but that is also    not
the question raised.The question is about how do OOB events that WSRP   
actors receive impact the defined protocol between the actors.   
    

    

    I think the most common case (#1 below)
   is one where the portlet (or the application it is a front for ... the
   protocol does not distinguish between these) receives information from
an    outside source (e.g. a stock quote portlet receives updated trade  
 information). I think this is the most trivial case and is likely just a
   matter of including any related coordination information in the next  
 interaction cycle, but I do think that we should keep such scenarios in
mind    as we design WSRP coordination. 

    [Yossi    Tamari] But since the user may never interact with this
specific portlet,    and it may not be the recipient of any events, and its
markup may be    cached, this portlet may never be called again. So how can
we design a robust    mechanism to support this? 

    

Rich Thompson 

    

    

   
    
     
     

              

          
          Andre Kramer          <>
         
          
08/06/2003 04:27 AM
          

       
                  

                  To:                 
          

                  cc:                 
          

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

         

    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