[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-coord] Groups - WSRP Coordination SC biweekly call modi fied
Fine for me too.
-- Andre
-----Original Message-----
From: Tamari, Yossi [mailto:yossi.tamari@sap.com]
Sent: 30 July 2003 09:32
To: wsrp-coord@lists.oasis-open.org
Subject: RE: [wsrp-coord] Groups - WSRP Coordination SC biweekly call
modi fied
I can live with a 9am meeting. (This week and regularly).
Yossi.
-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: Wednesday, July 30, 2003 3:19 AM
To: wsrp-coord@lists.oasis-open.org
Subject: Re: [wsrp-coord] Groups - WSRP Coordination SC biweekly call
modified
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
>
>
>
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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]