On 07/19/2012 01:13 AM, Rafael Schloming wrote:
On Wed, 2012-07-18 at 19:05 +0100, Gordon Sim wrote:
On 07/18/2012 05:40 PM, Rafael Schloming wrote:
So while the Proton mission is in many ways compatible with the
original Qpid charter, the de facto Qpid mission of today is really
quite different from Proton's.
I tend to disagree.
I should have pointed out that while I have a different, though I think
not entirely opposing, view to you on this one aspect, I agree entirely
with the bulk of what your wrote.
In my mind, the purpose of Qpid has always been to develop software
under the ASF governance and licensing in order to support adoption of
AMQP and the emergence of an ecosystem built around it that better
serves users needs.
As I stated above, I agree that the Proton mission is compatible with
the original Qpid charter, but I believe they are still quite different.
The above statement permits the development of just about any kind of
application that happens to speak AMQP since that furthers adoption of
AMQP.
Yes, I think in my view that is indeed the case.
The Proton mission on the other hand is about making it as easy as
possible for any application (either existing or under development) to
speak AMQP. This really doesn't include building any such applications
as part of Proton, and doing so would compromise Proton's embeddability
and neutrality.
To my mind, that is merely stating that Proton plays a specific, well
defined role in achieving the Qpid mission. The same is true for e.g. a
JMS client. Qpid's mission as a whole encompasses the different strands.
At the time Qpid was formed, that meant client libraries and messaging
brokers. We have always wanted to have embeddable libraries that other
broker/clients/frameworks/etc could use to support AMQP however.
As AMQP has evolved, a clearer, cleaner layering has emerged. The
specification defines how different components can interoperate, rather
than attempting to define the behaviour an interchangeable message
broker (which the earlier specifications did not in fact achieve anyway).
In addition I think through developing and maintaining different
language implementations we have come to appreciate ways in which this
can be kept more manageable for maintainers and less confusing for end
users.
The landscape is therefore different now than it was when Qpid began. To
my mind however the mission of the project is not, though we should
always be prepared as a community to re-evaluate how best to achieve it.
I think the problem is that were we to reform Qpid in today's world, the
best way to support adoption of AMQP would not be to build yet another
broker, but rather to build a library that makes it easy to adapt all of
the many existing brokers to speak AMQP. That is certainly very much
where proton is aimed, but unless you're prepared to take the view that
we should dump the brokers and ignore existing Qpid users, it's a
stretch to say that the de facto mission is no different from the
original as the de facto mission clearly involves doing something with
the brokers we've built.
I don't think ignoring users is ever something we should do.
However I think we should always be fully prepared to re-evaluate how we
are achieving and re-prioritise if needed. As such questioning whether
the brokers or indeed any component are failing to adequately meet our
overall objective and if so to take appropriate action is entirely
sensible. What we have today need not constrain what we have in the future.
I do think that in the 1.0 landscape a message broker is going to be a
very, very common part of the deployed infrastructure. I absolutely
agree that we should be providing a library that makes it easy for any
existing broker to support AMQP. However I also think it is important to
have a truly open, ASF governed AMQP broker. I don't see these separate
strands as in any way in conflict.
I believe wholeheartedly in the development of a protocol engine for the
three 'platforms' mentioned (C, Java and JavaScript). I believe these
should be usable by any higher level component that wants to speak AMQP
in some way, whether part of Qpid or not.
It seems clear there is also opportunity for wide reuse of a 'driver' -
an IO subsystem as you put it - designed to work well with the engine,
for cases where that functionality is not already provided.
I also fully appreciate and welcome the expanded understanding of the
'API space' that these developments have brought into focus, though I
think there is still some thinking to be done there.
As I stated on another thread, I think we need a shift in emphasis. A
renewed emphasis on interoperability, a new emphasis on enabling an
ecosystem that is wider than perhaps first imagined.
To my mind this is not a change to the mission or Qpid, nor does not
necessarily negate the value of existing components (though again, we
should never be afraid to re-evaluate).
To be clear, I don't believe I ever proposed any sort of change to the
Qpid mission.
Indeed not, and I was certainly not implying that you did. I simply
meant that the 'defacto Qpid mission of today' is in my view the same as
it was at the projects inception. The changing landscape in which we
evaluate that mission, or any loss of focus on it that may have occurred
and need corrected, is a separate thing.
My point is that the Proton mission is just different to
the Qpid mission *of today* (if it were not there would be no point in
doing it),
I don't follow your logic there. I would say that the purpose of Proton
follows quite logically from the mission of Qpid, as your excellent
notes pointed out so clearly.
and depending on what you think the Qpid mission is or should
be, you may feel it is more or less compatible and/or overlapping with
the Proton mission. For example, lot's of people think that Qpid is
about building brokers, and that's pretty much entirely disjoint to what
Proton is about.
I'm firmly in the camp that is 100% comfortable with Proton being
entirely compatible with-, and supportive of-, the Qpid mission.
However equally I have no philosophical objection to spinning of proton
or indeed any other component(s) as a separate top level project in the
future. (Apache Hadoop is perhaps a good example).
An ASF governed, open, AMQP enabled JMS client is clearly a valuable
piece of the 1.0 ecosystem, as is a broker that can support the full
functionality that JMS defines. These should likewise be usable on their
own, against AMQP-enabled components developed outside Qpid, and outside
the ASF. They play a different role than proton in promoting AMQP, but
in my view are merely different initiatives supporting the same mission.
What's the important distinction between initiative and mission? I
certainly think you can interpret the Qpid mission as broad enough to
include a lot of things, but that simply begs the question of what are
the sub-missions/objectives/whatever of each initiative, and how are
they governed when they have distinct sets of users?
I agree, any task or artefact can generally be broken down into smaller
components.
(Indeed, if you'll forgive the digression, the very name of Proton
provides an interesting analogy there. The atom is no longer seen as
indivisible; the proton is itself composed of quarks).
To me the key is that they be governed in 'The Apache Way' - openly,
meritocratically, seeking consensus - as the best way to serve the
community as a whole.
As I said, I think the actual structure that makes the most sense will I
think become clearer with time. I can see merit in all three of the
hypothetical scenarios you listed.
Lets get through a couple of proton releases; lets grow the community
and hear how they get on using it; lets see where the deeper
understanding of APIs that has emerged leads us; and yes, by all means
lets re-evaluate what we are doing along side proton.
I anticipate new behaviours and components that can be built on top of
the core AMQP protocol in the future and what better place to explore
and develop those than here at Qpid, under an established, well
respected governance model? I think we also have a responsibility, and
perhaps a unique position, to help bridge users of the earlier revisions
of AMQP onto the better world that 1.0 promises, the users that in large
part have fuelled that very evolution of the specification.
How do you define what is in/out? If I write a chat server, distributed
ray tracer, or MMO that happens to speak AMQP, is Qpid the perfect place
to build these things?
I think to me an important question is what the primary purpose of the
hypothetical component is. The primary purpose of an AMQP broker is to
be an intermediary in AMQP-based communication and that I think is
within the scope of the mission. The primary purpose of a ray tracer
seems on the face of it to be out of scope to me.
However, such decisions should always be based on debates in the
community. We don't want one-man projects, we want community initiatives
and the community can thrash out the best structure.
What structuring makes most sense is something I think will become
clearer organically as we make progress. The key is - as always! -
continual, open communication and debate, not only amongst the
developers but with users in the widest sense.
I think it's important to recognize that Proton needs to be *neutral*,
i.e. it is a general purpose library that any application can use to
speak AMQP.
Agree 100%.
It can't favor any one particular application's usage of
AMQP, for example Bundling together a JMS Broker with Proton would
obviously give any existing JMS vendor pause if they were considering
using Proton to support AMQP.
I don't think anyone is proposing bundling a JMS broker with the
library. I believe the intention is to have them as completely separate
artefacts. The svn structure was explicitly designed to make that clear.
The fact that a broker might be available from the same source is an
entirely separate thing. I don't see why a vendor who found one
component useful would be hindered from using that simply because they
offered an alternative to some other component.
As you point out, proton has evolved towards providing a general purpose
API. Now a broker vendor may well have their own APIs and clients, and
could in some sense be seen to be offering an alternative even to
proton. They are free to pick and choose the pieces they find is useful,
and indeed to get involved in shaping those pieces.
So while it's all fine and well to paint a picture of Qpid as an
umbrella project which is open to all things AMQP, that picture is
missing an important distinction between software that underpins an
ecosystem (e.g. the TCP stack), and software that is part of an
ecosystem (e.g. an http server).
Yes, that is a good distinction. To me though it simply distinguishes
different roles. It doesn't in and of itself mean that different layers
in the stack can't be used and developed in the same community, even if
some users choose different sub-sets of that stack.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
