This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
(from a note conversation with Antoine Mensch) Eventing currently defines an Event Source as: A Web service that sends notifications and accepts requests to create subscriptions. This isn't quite accurate. An Event Source does accept requests to create subscriptions, but who actually sends out the notifications is an implementation detail. For example, the endpoint that accepts the Subscribe() could be very different from the endpoints/components that actually send out the notifications - it could just be acting as a sort of proxy/manager. Proposal: Modify the defn to read: A Web service that accepts requests to create subscriptions. If we don't want to lose the tie-in with notifications, perhaps something like this: A Web service that accepts requests to create subscriptions for a certain set of notification that might be generated.
for proposal 2: s/notification/notifications/
Created attachment 777 [details] A proposal to issue 7970 A proposal to issue 7970 that can support the existing as well as the clustering deployment model. Use case: In some data center or high volume event processor, events may be delivered from a special event dispatcher or from a pool of high speed event dispatchers, not necessarily from the event source endpoint. Rationale and benefits: 1) Event dispatcher pools can be shared by all event sources to improve the event dispatch throughput. 2) These event dispatchers can be on high speed links (IP addresses) as part of the infrastructure. 3) There is no need to implement a http client event dispatch for every single event source. For example, there might be 10,000 individual event sources on the platform, but only 10 high speed event dispatchers. 4) For some resource limited devices, the resource hungry event dispatcher may reside in a separate but more resourceful environment from the event source. The attached proposal supports this clustering deployment model . In addition, by making the event dispatcher explicit, it supports the pull-model in event delivery and IP-blocking as in current model.
Created attachment 778 [details] This is a revised (v.2) version proposal to issue 7970 Tthe last paragraph of the previous proposal is removed to address an issue with pull-model event delivery. - Wu Chou
new proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Nov/0022.html
Another sentence that would need to be changed: -- As described previously, event sources transmit events to event sinks as SOAP messages called "Notifications". -- to -- As described previously, events are transmitted to event sinks as SOAP messages called "Notifications". --
from external reviewer point 3
Latest proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Nov/0022.html plus: change: -- As described previously, event sources transmit events to event sinks as SOAP messages called "Notifications". -- to -- As described previously, events are transmitted to event sinks as SOAP messages called "Notifications". -- plus: change: -- Event Source A Web service that accepts requests to create subscriptions. -- to -- Event Source A Web service that accepts requests to create subscriptions for the subscriber to receive certain type of notifications. --
amended: - - - - - - Event Source A Web service that accepts requests to create subscriptions. Notifications MAY be sent by any endpoint including the event source. Notification A message sent to indicate that an event, or events, have occurred. - - - - - - -
resolved with the combination of comments 7 and 8