Re: [Hawkular-dev] Should the components depend on the bus ?

IMHO, the communication should be built into the components precisely because they are meant to be components - parts of a bigger picture. In that scenario, you will rarely encounter usecases where no communication between the components is needed. Fabric1 have zookeeper for similar purpose, kubernetes have etcd similarly, too. I am a little bit nervous about using a bespoke solution for that though - but as long as it is made such that clients NOT using our bus implementation can still communicate with "us" over the actual channel, I'm ok with that (which from the little I have read seems to be the case). Granted, we could abstract the communication out into the glue code as you suggest and it would work but I think the potential problems with that approach outweigh the requirement for the components to publish events onto the bus. Any change in the component API (or behavior!) would have to be reflected in the glue, too. The glue would become the bottleneck or would be massively harder to deploy in a distributed manner. that we should strive for separation of concerns as much as possible. But given the fact that our components are meant to work together, I think that communication over bus is one of the core requirements for each of them. Maybe there should be a config flag to switch such communication off for the times where the components will be used outside of hawkular. But I don't think it is worth the effort to suppose that the components will primarily be used and deployed on their own - I think the opposite is true. On Tuesday, January 20, 2015 10:28:30 Thomas Heute wrote: Note that in the DumbFeed example, things would work even without the notification. Things would just not be that friendly - basically stuff would not automagically appear in the "discovery queue". The user would still be able to set up the resource with the metric. They would just have to "remember to do so" and use manual look-up to stitch things together.