Le 14 févr. 2013 à 23:42, Brian Stansberry <brian.stansberry(a)redhat.com> a écrit :
Just some basic categories of use cases:
1) Internal to the server. See usage of ControlledProcessStateService
for an example. It's essentially a notification emitter for a couple
specific management events.
A lot of internal to the server use cases though might be better done
with services though. For example, say a service injects a
SocketBindingService to learn it's socket configuration during start.
Then that service wants to listen for notifications of changes to the
socket binding config. Is it better off listening for messages from a
generic notification mechanism, or should the SocketBindingService
itself generate events?
In this case, I'd still use a generic notification mechanism. The SocketBindingService
will have its configuration changes through calls to :add/:remove/:write-attribute
operations in any case, right?
The service that injects a SocketBindingService could register a listener on the SBS's
path address and be notified on any config changes.
I think we could also allow any resource (or service) to generate well-defined
notifications too (e.g. when a host joins/leaves a domain) but notifications from
:add/:remove/:write-attribute could cover most of the use cases.
jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/