On Tue, 2013-01-22 at 17:31 +0100, Rob Godfrey wrote: > On 22 January 2013 17:12, Rafael Schloming <[email protected]> wrote: > > > I have directly experienced some of the opportunity cost that Justin speaks > > of. I once observed someone (a director level decision maker) being very > > surprised to be informed that qpid is actually *two* brokers. He had ruled > > it out as an option entirely until he found out that we actualy have a Java > > broker that speaks multiple versions of the protocol. > > > > Yes - this is the sort of thing that I think we need to make clear from the > starting point of the website. What components we have, what the can be > used for, and what components we are looking to build. > > I think the general idea of having other libraries and services at the same > level as proton makes a lot of sense... however given the way that the Java > tree is constructed (I can't speak for the C++), it'd be a little hard to > arrange right now and having a top level entry corresponding to "java" > probably wouldn't help with the silo-ing which you describe below (moreover > it really doesn't make much sense from a user perspective either). > > So a directory structure which had top level entries something more like > > ** proton > ** Java broker > ** C++ broker > ** JMS client > ** Messaging API client(s) > ** AMQP proxy > ** AMQP router > ** Management Console
If we do the split that way (which seems reasonable) then we have to think about where to put libraries used by more than one component. e.g. for C++ we have libqpidcommon and libqpidtypes that are used by both the broker and the C++ messaging API. I can think of 2 ways to do this: 1. create extra top level directories for the common stuff. 2. Put common stuff in the "lighter" component and have the "heavier" component depend on it (e.g. C++ broker depends on C++ messaging API). 3. duplicate the code I'm happy with 1 or 2, not 3. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
