Closed bjhargrave closed 10 years ago
Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>
OSGi Compendium R5, 113.6.5 Service Event, defines those event properties:
• event – (ServiceEvent) The original Service Event object.
• service – (ServiceReference ) The result of the getServiceReference method
• service.id – (Long) The service's ID.
• service.pid – (String or Collection
My suggestion is that we can have one bullet more to specify that all service properties are visible as event properties in case of no collisions. "objectClass" can be ignored, because it's available as "service.objectClass".
It'll provide filtering to the asynchronous service notifications and can speed up the work of incoming specifications like ZigBee, Network Info, Device Abstraction Layer etc.
Comment author: @bjhargrave
CPEG call: We discussed and thought this might be a good idea. Can you please start an RFC to update Event Admin for this change? It was felt an RFC is necessary to flesh out the requirements and all the design details. And to potentially hold any other possible improvement in a next version of the Event Admin spec.
Comment author: @cziegeler
Just for the record, I'm interested in some updates for EventAdmin as well
Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>
(In reply to Carsten Ziegeler from comment BZ#2)
Just for the record, I'm interested in some updates for EventAdmin as well Next week, I'll put that issue in a new RFC document. Meantime, feel free to share your ideas in the mailing list or bugzilla.
Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>
Initial RFC document is available for comments/feedback: https://www.osgi.org/members/gitweb/design.git/tree/HEAD:/rfcs/rfc0211
Comment author: @bjhargrave
CPEG call: Closing now that RFC 211 is covering this topic.
Original bug ID: BZ#2643 From: Evgeni Grigorov <e.grigorov@prosyst.com> Reported version: R6
Blocker for: BZ#2724