On 01/21/2013 05:22 PM, Rafael Schloming wrote:
The users of a piece of software inherently shape its
direction, and forcing two pieces of software that need to be quite
independent to have a single user group is going to influence and shape
that architecture in a way that is contrary to them being independent in
the first place.
Having a single communication channel for a community is not the same as
forcing independent pieces of software to have a single user group. No
one is 'forcing' anyone into anything.
I don't believe having more conversations in the wider community need
have any negative impact on the architecture of independent components.
I think this is especially concerning because the dev and
users list are already largely established as the cpp/java broker lists.
I think the lists are as much about the clients (and indeed management
mechanisms) as the brokers. I see them as being places where all the
components have been discussed, in combination with each other or in
conjunction with software outside the project (RabbitMQ, Mule etc etc).
The conversations evolve as the components evolve. Ultimately people
talk about what they are interested in and what they are using. None of
our lists are particularly high volume at this point, so I am of the
opinion that there is more benefit to sharing a channel of communication
than there is from segmenting it.
It is my
belief that if AMQP is successful the architectural layer represented by
the protocol engine + messenger, and the various applications that use it
(qpid-cpp, qpid-ava, activemq, and more) will ultimately be strongly
reflected in their own distinct communities and it may well be as strange
and alien to think of merging the communities/lists as it would be to
combine the TCP stack/socket API into a single project with the apache web
Time will tell of course, but I myself take a different view. I think
the analogy is somewhat flawed.
I think AMQP will have a community of interest around it, a community
that is specifically driven by the vision of interoperability, of
composing systems from many different parts. Not all members of that
community will be interested in the exactly the same set of components
of course, but I think there will be a lot more common interests than
your analogy would suggest. I think there will also be general issues
that are relevant to different components (e.g. global addressing).
Having an AMQP focused community at Apache and having that community
discuss various different components with different architectural
relationships seems entirely natural to me.
Already it's hard to imagine how the details of implementing ssl
support in proton and the details of implementing a transactional
persistent message store will significantly benefit from cross
In my view that entirely misses the point. Those topics themselves may
seem quite distinct, but there are many people who would be interested
in both of those topics. There are also likely some people who might be
interested in knowing a bit about them and/or contributing to
discussions around them even if they are at present primarily focused on
some other component entirely.
Clearly users of proton's messenger API may be interested in
communicating with a persistent transactional store. Users of other APIs
might be interested in how the messenger API differs in that use case
with whatever API they use. Implementers of such a store may be
interested in proton's engine API (as well as some other broker/brokers).
So even with these two distinct topics it seems to me (at the risk of
repeating myself to the point you all stop listening and filter my
emails to /dev/null!) that there are benefits to sharing a communication
channel and at present no real concerns about excessive traffic (at
least none so far expressed).