[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-coord] Groups - Discussed Eventing Semantics.doc uploaded
Great to have something this concrete to discuss at this stage. I've collected together my first comments (we could pick some off as we walk through):
regards,
Andre
------------------------
"the Consumer can act as intermediary for distributed events"
Should this be an explicit goal? I see the consumer as a "broker" in that it can selectively forward events - not just a simple intermediary.
"are generations of events synchronized"
I would only say that: "Events from any one portlet are delivered to all other interested portlets in the order raised by the portlet, but interleaved with events generated by others."
"Is page load a user interaction?"
Should we provide an "EventHandlingContext" to markup operations? This could signal "first load" and provide a (cached) list of portlets that share the scope/page or are 'wired together'?
This, and other considerations such as event source identification, supposes portlets can be identified e.g. soap_markup_access_point_url:portletHandle
If nothing else, EventHandlingContext would be useful for carrying vendor extensions for coordination.
2.1.1 PortletDescription
We should consider some sort of event "topic" hierarchical structure. The topic trees of WS Notification may be more than we need, but listing all possible events individually may be costly. A simple "root/parent/child" which matches the "child" sub-topic and sub-topics below it seems reasonable.
Minimally, we should have an "all/any" event wildcard for generatedEvents/handleEvents.
e.g.
wsrp:anyEvent for handleEvents means pass all generated events.
wsrp:anyEvent for generatedEvents means that any event can be raised (in addition to those listed).
PortletDescription
boolean alwaysCallHandleEvent
On any performBlockingAction on any Portlet in page/scope call HandleEvent for this portlet, even if the action processing (i.e. pba) did not raise any events. The event list passed would be empty (or just event target), but the EventHandlingConext would indicate "user action".
This gives a portlet the chance to update itself or coordinate other portlets on ALL user interactions.
PortletDescription
boolean notifyFailure
boolean notifySuccess (don't expect this to be used much)
States whether the portlet must be called using handleEvents() with an EventHandlingContext indicating status of last interaction processing step:
"handleEvent processing failed" or "handleEvent completed normally"
"handleEvent processing failed" notification is a MUST if notifyFailure
"handleEvent completed normally" notification is a MUST if notifySuccess
3.1.1. UpdateResponseType
Should we move the [O] Event events[] to "BlockingInteractionResponse"?
It would be difficult to switch into event processing if parallel update responses are being returned using UpdateResponse? But still mutually exclusive with redirectURL.
3.1.2 EventDescription
name, type instead of eventName, eventType?
Do we need event title/shortTitle for event UI (lists and tooltips)? See event naming and nesting using "/" suggestion above.
"A reference to a schema-defined" what? "for the" ...
3.1.4 EventType
We need to include the event source (see above comments on portlet identification).
EventType
[R] String source
name, type instead of eventName, eventType?
"Any pre-defined events" - TBD we should provide a way for interested parties to define such sets (e.g. for Portals).
"Any reason to define a means by which events can appear in a hierarchy?" yes, but mainly so that we can do basic filtering for "eventHandled" and allowing partial declaring of generated events (as a topic and all sub-topics).
3.1.3 EventPayload type
It would be safe to include the any (namespace other) directly in the EventType so that we don't need this structure.
3.2 handleEvents()
newNavigationalState returned?
Are re-directs allowed?
MarkupParams in:
secureClientCommunication
clientData? locales? mimeTypes? markupCharacterSets? ValidateTag (also for invalidation)?
validNewModes (if mode changes allowed)
validNewWindowState (if windowState changes allowed)
3.2.1
Seems a bit strange to do per-portlet event arrays rather than per-producer event/portlet arrays from a protocol optimization point of view. I'd say we do it more because it is convenient and addresses the normal case (one or two events to a portlet). This also makes failure semantics be per-portlet rather than per-producer!
-----Original Message-----
From: richt2@us.ibm.com [mailto:richt2@us.ibm.com]
Sent: 28 January 2004 18:35
To: wsrp-coord@lists.oasis-open.org
Subject: [wsrp-coord] Groups - Discussed Eventing Semantics.doc uploaded
The document revision Discussed Eventing Semantics.doc has been submitted by Rich Thompson (richt2@us.ibm.com) to the WSRP Cross-Portlet Coordination SC document repository.
This document is revision #1 of Discussed Eventing Semantics.doc.
Document Description:
Updated to reflect today's discussion. I also attempted to move questions to the areas they relate to.
Download Document:
http://www.oasis-open.org/apps/org/workgroup/wsrp/wsrp-coord/download.php/5200/Discussed%20Eventing%20Semantics.doc
View Document Details:
http://www.oasis-open.org/apps/org/workgroup/wsrp/wsrp-coord/document.php?document_id=5200
Revision:
This document is revision #1 of Discussed Eventing Semantics.doc. The document details page referenced above will show the complete revision history
PLEASE NOTE: If the above links do 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.
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to 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]