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).

Reply via email to