qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <...@alum.mit.edu>
Subject Re: mailing lists and fragmented communication
Date Mon, 21 Jan 2013 17:22:11 GMT
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 <kgiusti@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-broker@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 <kgiusti@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-unsubscribe@qpid.apache.org
> > > > For additional commands, e-mail: users-help@qpid.apache.org
> > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message