Re: [wsrp-coord] Groups - WSRP Coordination SC biweekly call modified

[Michael Freedman <Michael.Freedman@oracle.com>]

Oops.  I forgot to send out a query seeing if we can reschedule these 
for 9am ... as I have a standing 8am internal meeting now I can't make 
this time.  Any chance we can reschedule future events for some other 
time on Wednesday?  If by luck folks can postpone tomorrows meeting 
until 9am let me know as I will check my e-mail in the morning before 
heading into my 8am.

As I am unlikely to be on tomorrows call, here are some thoughts on the 
presentation/questions below:

1. Is someone going to flesh out the MultiMedia Sports scenario a little 
more.  In thinking about the problem in general I understand the need 
for data to be interchanged between portlets controlled by a consumer 
but haven't yet come up with good examples where events are needed.  The 
current description of the scenario doesn't illuminate this.  Can 
someone help me?  Because I think that if we can get away with only 
needing to represent model/data we will end up with a simple API that is 
clearer to use [in a manner that works efficiently].

2a.  I think we need to define/publish transparent state however I don't 
think we need information related to scope/etc.  Is this there because 
some folks want the consumer to manage this state for the producer 
outside the opaque mechanisms we have?  I think this would be an 
unneeded overcomplication. Why can't we get away with having a producer 
merely publish a model of its public data and leave it to it to decide 
how this maps to state/scopes?  I.e. A producer returns a representation 
of this model on performBlockingInteraction. [As an optimization we can 
have the consumer pass information to the performBlockingInteraction 
regarding what model elements it cares about/if any]. A consumer 
mediating state between itself/other portlets that receives a model back 
from a performBlockingInteraction is able to push this state through to 
other portlets via an UpdateModel call.  This call in turn returns a 
model and the sequence continues until the consumer detects no more 
updates are needed or it detects a deadlock.

2b. Need for opaque portlet-defined events. I don't yet understand/see a 
need for portlet defined events.  If we don't need them I also don't 
understand why we need events at all.  Do we have enough if we just 
focus on communicating state/data?

2c. Should we piggyback event delivery on existing operation signatures? 
 Yes and no.  At this point [until generic events are justified] As per 
above we need to extend the performBlockingInteraction call to carry 
information.  But we also need a new call to handle the dependent 
updates [UpdateModel].

2d.  [New questions] My statements above assume that data changes 
[events] never happen/get communicated out of band.  They only happen in 
response to a user action.  Do we have requirements to allow the portlet 
to trigger an out of band indication that state has changed?  [I hope 
not].  How about an in-band one where you aren't the target of an action 
or are asked to update your model?  [Only if we can live with allowing a 
flag to be returned by render that indicates to consumers that can deal 
with it that their model has changed, so that the consumer can choose, 
if it wants to, to remember this and manage the state chanegd processing]

     -Mike-

richt2@us.ibm.com wrote:

>WSRP Coordination SC biweekly call has been modified by Rich Thompson (richt2@us.ibm.com).
>
>Event description:
>USA Toll Free Number: 866-769-7222
>USA Toll Number: +1-203-566-0687
>PARTICIPANT PASSCODE: 377048
>
>Agenda:
>1. Considering the scenario assigned for driving SC work, the MultiMedia Sports scenario, does the offered presentation capture the items we need to consider?
>
>2. First set of questions to consider:
> - Need to define transparent publicized state?
> - Need for opaque portlet-defined events?
> - Should we piggy-back event delivery on existing operation signatures?
>
>
>Date:  Wednesday, 30 July 2003
>Time:  11:00am - 12:00pm Eastern Time
>
>This event is one in a list of recurring events.
>Other upcoming dates include:
>
>Wednesday, 09 July 2003, 12:00pm to 01:00pm Eastern Time
>Wednesday, 13 August 2003, 11:00am to 12:00pm Eastern Time
>Wednesday, 27 August 2003, 11:00am to 12:00pm Eastern Time
>Wednesday, 10 September 2003, 11:00am to 12:00pm Eastern Time
>
>
>View event details:
>http://www.oasis-open.org/apps/org/workgroup/wsrp/wsrp-coord/event.php?event_id=1670
>
>PLEASE NOTE:  If the above link does not work for you, your email
>application may be breaking the link into two pieces.  You may be able to
>copy and paste the entire link address into the address field of your web
>browser.
>
>
>
>You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrp-coord/members/leave_workgroup.php
>
>  
>