RE: [wsrp-coord] Questions about events

"Supporting properties" is an extension/upgrade to our existing property mechanism that allows portlets to send/receive data values between the consumer and other portlets. I.e. Rather then a portlets data depending on either its current model state or values passed in the request from the client, "supporting properties" allows a portlet to in addition depend on the state of another portlet. This is commonly used to orient a set of related portlets within a page. For example I may have various news syndication portlets on a page that I would like to display current articles based on a new category I can set in another portlet -- i.e. one portlet to choose the focus while the other portlets display article/data constrained to this focus.

As Yossi has pointed out any general purpose event mechanism we define should be capable of also supporting transmitting portlet state. There are reasons however to represent/model this function independently:
a) better fit for the user case(s). The above scenario not only requires the ability to communicate new values when state changes but also initial values. For example the portlet that sets the focus likely has a customization property for setting the default topic. Its more natural to ask for these initial values directly vs. sending an event.
b) provides a simpler programming/design model. Events typically represent actions [verbs]. Its certainly possible to represent data [changes] as actions. Choosing not to reduces the portlet developers design decisions to merely what data do I want to expose vs. what events/actions will I communicate. This has an important impact on the page developer/end user/receiving portlet developer when they are wiring based on state as the firing portlet will likely have many events that carry similar state. Mapping data value X to data value Y is a simpler model for such users then Mapping data value X from event M and data value X from event Q and data value X from event W to data value Y. Basically, "supporting properties" constrains portlet developers [makes it simpler for them to design their portlets] and results in simpler systems overall.
[Yossi Tamari] I have a few comments regarding this:
First of all, as you said at the end of the message, the properties a portlet exposes for coordination is completely different than the properties it exposes for customization. Therefore the initial state is as much a problem with properties as it is with events.
Also, as you said bellow, normally changes will be generated as a result of a user interaction. User interaction is much more naturally described by a verb (event) than by the state change that it causes to a specific portlet. In other words it makes more sense to send an event ItemSelected("umbrella"), than to expose a change to the internal property MyThirdSelectedItemInTheThirdPaneOfTheForm with the value "umbrella". (In other words, in order to make sense, exposing a portlet properties will probably require the portlet to map each of its properties to a nice external name. We don't even know if this portlet has a property for this at all - it may be that when "umbrella" is selected, the only thing that changes is the navigational state (or simply a form is generated with "umbrella" in one of the fields.
Finally, the complex mapping you describe can be needed in the property model as well, since it is very common to require two properties to need to change together (like SelectedItem and Price).

That all being said, though I prefer [and think many portlets will prefer] the state interchange model, its okay if we decide to support both. I.e. the premise that there are things that are best represented exclusively as actions/verbs. However, if we support both I would expect it to be differentiated. We would recommend that portlets not use Events to model state interchange/data changes rather events would be used to communicate all other logical portlet actions.
[Yossi Tamari] Of course I disagree with this recommendation. Events should be used to model user interactions. State changes should be used to model logical state changes that have some application logic associated with them. This means state changes are better for more complex, strongly tied, portlet applications, while events are for more loose, UI based coordination.

As for your questions:
1. Agree with Yossi, namespace:name.
2. Well its the name of the event + associated data. The data is specified by the event. It has the same generality as our ModelDescriptions -- i.e. can represent types [its not attribute/value].
3. Actually, anything can send an event. The most likely culprits are portlets and the consumer itself. Basically an event is as stated in 2: a namespace:name + data. As we say later that a broker sits between the sender/receiver we don't ultimately care how many different channels/formats the broker can listen on. We, obviously will define the WSRP protocol for sending an event from the portlet to the broker. Namespacing will likely be a problem in this system as it will be difficult to guarantee uniqueness. We may have to define a convention ala Java, namely company.producer.
4. Actually, any part of the consumer/application can receive events. Again, most typically its other portlets or the consumer itself. We, obviously, will define the WSRP protocol for posting an event from a broker to a portlet.
5. No, they are only aware of events. A event can optionally carry data that publishes a service [port] for the receiver to use for P2P comunication.
[Yossi Tamari] There are other reasons a receiver may want to know who the sender is. I agree that we can leave this to portlets to define on their own, but there may be value to defining this as an optional parameter in the protocol.
6. We will likely have to define mechanisms for both synchronous and asynchronous sending of events from portlets. We will likely only support portlets receiving synchronous events.
7. Leaving out for the moment out-of-band/asynch events, the scope is "Before Rendering". Event processing, like actions will have to complete before any portlet rendering occurs. As an event change is typically kicked off as a result of an action [though a consumer will have the rights to send an event when no action has occurred] the scope can largely be thought of as "Action". This becomes even more true as we have to deal with action/event redirect. We certainly want an action to be able to return an event & signify a redirect -- with the likely behavior being processes the event chain then do the redirect. Its unclear whether we want event processors to be able to return their own redirects [I hope not].
8. There is an event broker. For in-band events the consumer [not the producer] knows the identity of the broker. For out-of-band events the producer will need to know this identity [or at least a proxy for it. At a minimum brokers will be required to dispatch posted events to portlets that have published that they want to receive that event [by name]. Many brokers will implement/support a mapping system. I.e. a portlet publishes: events it sends, events it receives [by name(space)], and mappable events. Mappable events describe a logical event the portlet would like to receive and requires the broker support defining/dispatching from one event structure to the other.
9. Yes, just like you described.
10. Because there is a broker it is Pub/Sub. To handle the case where the receiving portlet knows the particular event it wants to receive, then Yossi's namespace wildcarding seems interesting though we will have to balance this with worries that portlets will use this too liberally and cause performance problems.
11. Yes, its part of the "portlet description". We will have to decide whether to carry it in PortletDescription i.e. getPortletDecription()/getServiceDescription() or via a separate call. If the former we likely would want to pass a boolean indicating if we want the information. If the later the PortletDescription would likely carry a boolean indicating such information exists.
12. One of two ways: either it publishes explicit events it wants to receive or it publishes logical [mappable] events.

One question you don't ask about is authorization/security. Its easy enough for a set of cooperating portlets within a single producer to restrict access to interchanged data by merely not carrying any data in the event. But how does this work when the porlets aren't in the same producer? The downside of the broker model is the sender has no control over the who are the receipients of its information. Will we need to build some support here?
[Yossi Tamari] No. If a sender wants too have security on its payload, it should use encryption on it and make sure only the intended receivers have the key. This is outside of our scope.

And finally, to keep the state interchange model in sync let we reask your questions:

wsrp-coord message