It's really about architecture and audience and how they interact. The architecture we are currently developing is closely modelled on the existing architecture of the internet. At the lowest layer the TCP stack provides a very general purpose protocol to a very wide range of applications. This is directly the role the protocol engine plays for AMQP.
Slightly above that in the software stack the socket API makes it easy (relatively speaking) for your application to speak TCP. Again this is identical to the role that the Messenger API serves. Neither the socket API nor Messenger provide you direct control over every aspect of the protocol details, but they do make it easy to interface to the basic functionality of the respective protocols and they provide you indirect access (via intermediaries) to many more advanced capabilities of the protocol. At the highest layer applications build on top of the protocol. In the case of TCP there are many thousands of applications including very important ones like HTTP, SMTP, etc. For AMQP, we currently have three examples at apache (the cpp/java brokers, and activemq), however I believe there are potentially many many other applications that could build on top of AMQP, perhaps even as many as currently exist on TCP. >From this perspective, I would assert that both messenger and the protocol engine have potentially very cross-cutting and broad audiences, whereas the brokers (relatively speaking) have inherently narrower and more domain specific audiences. While I can sympathize with the idea that a single broadcast communication channel might make it easier to explain this picture in the short term, I am deeply concerned that it will lead to distortion of this picture in the longer term as architecture tends to follow audience. 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. I think this is especially concerning because the dev and users list are already largely established as the cpp/java broker lists. So to answer your question, I don't actually think the arrangement of mailing lists will make all that much difference in the short term, that is something we need to proactively work on through other means, however I do think it can have a significant influence in the long term. 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 server. 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 communication. All that said, my primary concern is to promote a good understanding and foster development of the architecture outlined above, and this requires good communication beyond just the people who are on any of our mailing lists. If we can't explain proton to users of other qpid components, we certainly can't explain it well to the rest of the world. So if the above picture is well understood and there is still overwhelming consensus that merging lists will help achieve this goal then I won't stand in the way. I don't claim to know that we can't evolve to where we need to be through that path, merely that it worries me in some significant ways and that qpid mailing list communication in general is a very small subset of our overall communication problems, so any action (or inaction) we take with the lists should not make us feel better about having actually done something to solve the problem. --Rafael On Fri, Jan 18, 2013 at 4:15 PM, Ken Giusti <kgiu...@redhat.com> wrote: > Hi Rafi, > > You raise some good points, but I don't understand how keeping a separate > proton list makes it easier to provide a coherent view of the qpid project, > especially to newcomers. > > As you point out: > > > The project goals/identity issue > > in my > > mind has very little to do with the lists and more to do with the > > fact that > > many people think of qpid == broker, qpid cpp == cpp broker, and qpid > > java > > == java broker. While this understanding may have been more or less > > true at > > one point, it is now and going forward a misconception, yet we have > > done > > nothing to educate our users about this. > > > Agreed, and to that point, I think it would be a very bad precedent to > structure the mailing lists into component silos. Wouldn't creating a > separate mailing list for, say "qpid-cpp-bro...@qpid.apache.org", send > exactly the wrong message? Yet "proton@qpid.apache.org" somehow doesn't? > > If we really want people to think of QPID as being more than just a cpp > broker/java broker/etc, then we should start by revising the very first > paragraph of our homepage: > > "Introduction > > Apache Qpid™ is a cross-platform Enterprise Messaging system which > implements the Advanced Message Queuing Protocol (AMQP), providing message > brokers written in C++ and Java, along with clients for C++, Java JMS, > .Net, Python, and Ruby." > > > -K > > ----- Original Message ----- > > I think you raise a good point about the goals of the project being > > confused, but don't think the cause here is mailing lists. As we've > > seen, > > recent threads have asked about "qpid vs proton", and to a lot of us > > this > > is an odd thing to ask about because we think of proton as part of > > qpid. > > However we who are close to the project also think of qpid as > > something > > that is larger than just a broker. The project goals/identity issue > > in my > > mind has very little to do with the lists and more to do with the > > fact that > > many people think of qpid == broker, qpid cpp == cpp broker, and qpid > > java > > == java broker. While this understanding may have been more or less > > true at > > one point, it is now and going forward a misconception, yet we have > > done > > nothing to educate our users about this. I think this is really at > > the core > > of the identity issues, and if anything a separate proton list has > > helped > > raise these issues to the surface, because at least it is clear that > > proton > > is something that is self contained and distinct from the cpp broker > > and > > the java broker. > > > > I would hate to lose that distinction and have it all turn into one > > big > > jumbled muddle. I think rearranging the lists is not a substitute for > > rearranging the project and actively communicating about its > > structure. I > > may be in the minority with my -1, but I think there is actually a > > lot more > > work that needs to be done surrounding project structure, identity, > > documentation, communication, etc, and simply rearranging lists > > without > > doing the rest of that work is IMHO jumping the gun. > > > > --Rafael > > > > On Fri, Jan 18, 2013 at 1:14 PM, Ken Giusti <kgiu...@redhat.com> > > wrote: > > > > > I'm in favor of combining them all into one. > > > > > > If not that, then at least collapse the "proton" list. The level > > > of > > > traffic on that list isn't unreasonable, and, frankly, keeping it > > > separate > > > probably leads to some of the confusion we're seeing over the goals > > > of this > > > project. > > > > > > > > > -K > > > > > > ----- Original Message ----- > > > > I believe that we have too many mailing lists and that we are > > > > missing > > > > out on valuable collaboration and transparency as a result. > > > > > > > > Too often in the past topics have been discussed on the dev list > > > > without > > > > reflecting any of the discussion back to the user list, keeping a > > > > large > > > > part of the community in the dark. Now that we have a distinct > > > > list > > > > for > > > > proton there is the possibility of yet more fragmentation. > > > > > > > > I honestly believe that we would be better off with just one list > > > > for > > > > discussions. I think there will increasingly be issues that > > > > cross-cut > > > > different components or that would benefit from wider > > > > participation. > > > > Not > > > > all topics will be of interest to all subscribers, but that is > > > > always > > > > going to be the case. > > > > > > > > It doesn't seem to me like any of the lists are so high in volume > > > > that > > > > this would cause significant problems. More rigorous use of > > > > subject > > > > could help people filter if needed. (JIRA and commit notices I > > > > think > > > > do > > > > warrant their own lists allowing a lot of the 'noise' to be > > > > avoided > > > > if > > > > so desired). > > > > > > > > Any other thoughts on this? Does anyone have fears of being > > > > deluged > > > > with > > > > unwanted emails? > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > > > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > > > > > > > > > > >
