On 07/18/2012 02:05 PM, 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.
>
> 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. 

I agree with Gordon here,

Carl.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Reply via email to