Title: RE: [wsrp-coord] Events vs StateChanges
Yossi,
Thanks
for explaining the shared data model.
Still
seems to break encapsulation, as the consumer is directly involved in all
interactions.
On
event transformations - I'm not uncomfortable, just less comfortable (would
like to see examples).
Both
seem to model the consumer as a broker (mediating events or performing direct
writes) so maybe that's our core pattern?
regards,
Andre
-----Original Message-----
From: Tamari, Yossi
[mailto:]
Sent: 06 August 2003
10:30
To:
Subject: RE:
[wsrp-coord] Events vs StateChanges
Hi
Andre,
What
Mike is proposing is not that one portlet can change the state of another, or
send an event to another, but that it can declare its own state has changed,
and that enables consumers to change the state of another portlet when the
state of the first portlet is changed.
(In
other words, each portlet exposes a set of properties, that can be
readOnly\writeOnly\both, and the consumer reads state changes from one portlet
and writes them to another).
Of
course, this requires mapping, since there is absolutely no way for two
portlets to communicate without the consumer knowing which of their
properties need to be mapped. This is another huge advantage of the events
model, since if two portlets agree on the signature of an event, no mapping is
needed.
I do
not see why you are uncomfortable with event mapping. What is wrong in a
situation where a consumer decides that that portlet A exposes an event that
is logically the same as an event that portlet B subscribes to, and decides to
do some match-making? This would need tailoring at the page level by the page
designer at the consumer, and certainly not every portal would support this,
and the spec does not need to specify how it should be done. The model should
simply allow events to have enough metadata to enable
this.
Yossi.
-----Original Message-----
From: Andre Kramer
[mailto:]
Sent: Wednesday, August 06,
2003 11:10 AM
To:
Subject: RE: [wsrp-coord] Events
vs StateChanges
I've got some background in CCS & CSP so am used to pure
signals and very
comfortable with extending such a
(message based) model to carry data
(events (c) in
Mike's email). Another common extension is to add a broker
or event mediation layer (brokered events - i.e. the consumer routes
events).
I'm less comfortable with arbitrary consumer transformations
of events
and would like to see a proposal. Maybe
supporting event sub-typing
to allow a portlet to
register for generic sets of events would cover
most
use cases?
I'm very uncomfortable with any direct state based approach
(Portlet A
can update a shared variable on Portlet
B) as this seems to break
encapsulation even more
than consumer event transformation. Allowing
portlet
A to force a state transition on another portlet has similar
encapsulation problems.
Mike - for (d,e) are you proposing that portletA can do
portletB.write("variableName", "value")
or
portletB.goto("stateName",
"withData")
or ...?
regards,
Andre
-----Original Message-----
From:
Michael Freedman [mailto:]
Sent: 06 August 2003 00:58
To:
Subject:
[wsrp-coord] Events vs StateChanges
Last week we discussed the value of defining an in-band
event model vs.
a state changed model. Here
are some further thoughts:
I see the following types of events
that could be dealt with:
a) WSRP events -- these are well
known events that WSRP defines
-- currently these
"events" are implicit in our protocol being
explicitly represented as lifecycle calls [and their
parameters/returns]: i.e. perform action, render.
Examples of such
events we might consider adding are
Begin/EndTransaction. I.e. placing
a series of
calls between portlets within a consistent transaction.
[Important once we start propagating state changes/data across
portlets?]
b)
Mappable events -- these are events typically defined by the
producer [though also can be done by the consumer]
that the receiving
portlet is not aware of.
Consumers provide a facility to declare
mappings
from one portlets event namespace to anothers. Yossi indicated
he will provide some examples of this.
c) Known events --
these are events typically defined by the
producer
[though also can be done by the consumer] that the receiving
portlet is aware of. No mapping is necessary,
consumer merely route the
events to interested
parties. Commonly used within a producer to build
cooperation within a known set or portlets or by producers building
building-block portlets that it hopes other
producers will include in a
cooperating set.
d) Mappable state
changes -- probably the most common form of
mappable
event where the consumer acts as a mediator for data exchange
between two portlets. I.e. an action results
in state changes, a
portion of which a portlet
wishes to publish [e.g. bug report number].
The consumer understands that the portlet "publishes" this data
and
supports mapping it to similarly published state
in another portlet.
e) Known state changes -- like known events, the consumer doesn't
provide any mapping -- the sending/receiving
portlets understand/agree
on the data being
exchanged via prior knowledge/agreement.
I agree with Yossi that Mappable events are a generalization
of mappable
state changes. However, I am not
yet convinced that our in-band
mechansim needs this
generalization. For me there is a developer and
user cost/complexity to introducing MappableEvents here. As I
don't yet
have an example of a pure event -- one
that indicates no state
change/has no associated
state -- A mappable event leaves the developer
in
the quandry of whether to define a new event for every state change
or whether to expose the state changes via a common
event [e.g.
UpdateModel]. The later has the
benefit of having a single form
allowing the
consumer to present a simplified user interaction -- map
from this portlets published data to the other ones. When
individually
named events are involved the user must
first choose the event they want
to map and then map
the data between the events. For me, this is an
unnecessary complication to the user interaction. Until I
see/understand
the use cases for in-band mappable
events that aren't satisfied by
mappable state
changes my preference is to limit our in-band mechanism
just to mappable state changes.
As for (c) and (e) -- known events/state changes -- should
we care and
if so what is its priority?
Mappable events/state changes is a superset
of the
known case -- should we care and if so is it a priority to
support Consumers who merely want to deal with distpaching/managing
known events/state changes but not mappable
ones?
-Mike-
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
