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.
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.
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 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).
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.
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.
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.
There is much to do! Let's get on and do it, remembering all the while
to talk about what we are doing and be open and welcoming to all who
wish to collaborate.
--Gordon.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
