qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Trieloff <cctriel...@redhat.com>
Subject Re: proton: motivation and strategy
Date Thu, 19 Jul 2012 00:37:35 GMT
On 07/18/2012 08:13 PM, 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.
>>
>> 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.
>
> 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.


That seems like I fine goal to be a sub-project of qpid

>
>> 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 disagree, many project have not tackled the issues many messaging
projects have, and thus it is valuable to have a broker that serves the
user and also pushes on some of the technological boundries.

Qpid in many cases has introduced many other project to such capabilities.

>
>> 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. 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), 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.


Building a broker is part of the qpid mission, but providing protocol
libs, clients libs etc are also.

technically we could structure the protocol work (proton), client libs,
qmf etc into sub-projects....


>> 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?
>

they are all governed by the TLP Qpid.  they can each have there own
goals, etc and once they have a user base it becomes appropriate to
create lists etc once the traffic get to that point... I believe that
was the reasoning we used when qmf was debated in this light.

Carl.

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


Mime
View raw message