Group home page: http://groups.google.com/group/amqp-client-dev
I think it would be a good idea to move this discussion there since
this thread is getting cross posted across a couple groups who's
interest level varies. If this topic is of interest to you please
join the discussion there.
On Fri, Jun 11, 2010 at 9:01 AM, Rajith Attapattu <raji...@gmail.com> wrote:
> Frankly I am a bit baffled about the concerns raised here.
>
> Rob, Bruce, Rafi and a few individuals have expressed a desire to
> start an amqp protocol client project that is independent of any AMQP
> projects that already exist.
> The goal is to enable collaboration from anybody who is interested in
> AMQP and to avoid duplication of effort.
> To this end Bruce has extended an invitation to the developers in the
> Qpid/ActiveMQ communities to participate in this.
>
> **Also as Rob mentioned, it's upto the Qpid/ActiveMQ communities to
> use these client libs or not.** - However common sense suggests that
> we stand to be benefit if we use it, provided that it's designed
> properly which I am sure it will be.
>
> If we think pragmatically, there are many good reasons why such a
> project needs to be independent instead of being affiliated with an
> existing AMQP project.
>
> 1. All though Qpid, ActiveMQ, RabbitMQ etc.. are open source projects,
> they all have their own identity, their own communities, different
> companies backing them etc.
> If this proposed project goes under any of the existing projects
> then it is inevitable that people will feel that the chosen community
> will have more influence over the project than the others.
> This is not a good thing !
>
> 2. If this project is independent, then we will likely get
> participation from a wider audience, not just folks from the above
> mentioned communities.
>
> 3. It is IMO absurd to require a RabbitMQ developer to earn karma in
> the Qpid/ActiveMQ project to contribute effectively to this project.
>
> Regards,
>
> Rajith
>
> On Fri, Jun 11, 2010 at 4:04 AM, Robert Godfrey <rob.j....@gmail.com> wrote:
>> On 11 June 2010 08:48, Bruce Snyder <bruce....@gmail.com> wrote:
>>> On Thu, Jun 10, 2010 at 8:54 PM, Marnie McCormack
>>> <marnie.m...@googlemail.com> wrote:
>>>> I'm not sure what the best solution is, but I do know that I'm missing what
>>>> the problem using one of the Apache projects for this work is ?
>>>>
>>>> It seems like there some context missing from this debate, possibly from
>>>> discussions at the F2F.
>>>>
>>>> Bruce - can you elaborate on why other people might not want to work on AMQP
>>>> under an Apache project but would want to work on it as another open source
>>>> project and use an ASL license ?
>>>
>>> Why would someone who works on an AMQP broker implementation that is
>>> not Qpid want to come to the Qpid project to contribute to an AMQP
>>> protocol level client? If this project were hosted as a subproject to
>>> Qpid, it would forever be associated with Qpid instead of being
>>> neutral from any broker.
>>
>> Moreover those people would not find it possible to commit without
>> gaining committership to the relevant Apache project. I was talking
>> this evening to one of the guys from RabbitMQ who would very much want
>> to be involved in this - and I very much want to encourage this.
>>
>> I think we should see this idea as something that may be of interest
>> to particular Qpid, ActiveMQ, Rabbit or other developers... not
>> something that involves those projects in themselves. In the future
>> those projects may decide to adopt work that is done in this space (or
>> not)... but really what we are saying is that we feel like there are a
>> number of people from different communities who feel like it would be
>> worthwhile to have a go at this - and we're seeing how many other like
>> minded folks there are. There are, of course, also likely to be
>> developers in these communities to whom this is of no interest
>> whatsoever.
>>
>>>
>>>> It seems a little like double overhead for those already working on Qpid or
>>>> ActiveMQ to have a third project in the loop, with different lists and
>>>> process and all that. Having been around for a while I understand the
>>>> overhead with Apache, but I'm also concerned that we haven't really talked
>>>> about what we gain from a non-Apache project - what the gain from doing the
>>>> core libraries somewhere else ?
>>>
>>> Because it lowers the barrier of participation and is not associated
>>> with any particular AMQP impl.
>>>
>>
>> +1 I think it was a great sign that so many people from different
>> communities were willing to try to start up something like this - and
>> obviously if there are more people out there that will be even
>> better... I really want to do as much as possible to encourage this
>> effort and lower the barriers of entry for anyone who is interested as
>> much as possible
>>
>> -- Rob
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-su...@qpid.apache.org
>>
>>
>
>
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> http://rajith.2rlabs.com/
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-su...@qpid.apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
I think bruce just posted to our lists because he knew there would be
interested folks lurking in them. But the focus for these client lib
is certainly not centered around Qpid or ActiveMQ.
> This is a great idea and would be really useful for both projects on the
> Apache side.
>
> How many Apache projects are dependent on Google Code hosted libs for their
> core implementations ? I honestly have no idea but I think thats an
> important question for the Apache teams who will want to implement 1-0 in
> their brokers.
That happens all the time. As long as the dependency falls into a
category A license, apache projects are free to use and re-disribute.
>
> Is that not what you meant to suggest would be the end result Bruce ?
>
> If the objective is mainly about having a free/loose collaboration of
> individuals/organisations on an AMQP core libs then thats a different
> question, I think, and the detail is less important.
>
Yeah I think that's the general idea.
> Marnie
On Fri, Jun 11, 2010 at 10:15 AM, Alan Conway <aco...@redhat.com> wrote:
> On 06/10/2010 01:36 PM, Bruce Snyder wrote:
>>
>> On Thu, Jun 10, 2010 at 5:25 PM, Bruce Snyder<bruce....@gmail.com>
>> wrote:
>>>
>>> On Thu, Jun 10, 2010 at 5:17 PM, Lahiru Gunathilake<gla...@gmail.com>
>>> wrote:
>>>>>
>>>>> Hi Bruce,
>>>>
>>>> One consideration that we identified is that this work will probably
>>>>>
>>>>> need to take place outside of the ASF so that non-ASF folks can
>>>>> participate (we each agreed that Github would be suitable).
>>>>>
>>>> -1 !
>>>> I do not think this is a good approach to do this and we can always
>>>> start
>>>> this inside ASF as a sub project of Qpid and ask Non ASF folks be ASF
>>>> folks
>>>> !
>>>
>>> I disagree with hosting it under either the Qpid or ActiveMQ projects.
>>> This effort is separate from ActiveMQ or Qpid projects. It's focused
>>> strictly on AMQP 1.0 protocol handling. In a perfect world this effort
>>> would exist at the AMQP working group's website, but the working group
>>> is strictly against the creation and maintenance of any reference
>>> implementations. I suppose one other option is the creation of a new
>>> project at the ASF, but the only way to do that is via the Incubator
>>> and I'm not sure I want the encumbrances that that brings.
>>
>> I just re-read the Qpid website for a description of the project. The
>> most meaningful info I found is here:
>>
>> http://qpid.apache.org/amqp-compatibility.html
>>
>> So Qpid seems to be focused on its broker and client *implementations*
>> of the spec. The effort I proposed would be focused on a library to be
>> used for building AMQP 1.0 clients, not a broker-specific client
>> implementation. Like I said previously, the best analogy for this
>> effort is to the Apache Commons HTTP Client and the library it
>> provides for the HTTP spec. Many folks use the HTTP Client on which to
>> build apps and custom HTTP clients. This effort will provide a similar
>> spec-focused client library for AMQP 1.0.
>>
>> So having the project separate from any broker implementation is the
>> ideal.
>>
>
> Just read this thread and it makes perfect sense to me that the new project
> should not be embedded in ActiveMQ or Qpid.
> But that doesn't mean it shouldn't be an apache project.
>
> Paul Fremantle said:
>>
>> We could set this up as a labs project. http://labs.apache.org/
>>
>> I think that meets your requirements as being independent from
>> ActiveMQ and QPid. From there it could go via incubation and become
>> its own TLP.
>
> IMO making it a new Apache project makes sense since so many of the
> interested parties (ActiveMQ and qpid) are already involved in Apache. For
> those not involved in Apache projects, Apache is still a respectable place
> to host a project. I see no reason why e.g. RabbitMQ folks wouldn't
> contribute to an independent AMQP client project hosted at Apache.
>
> I've got nothing against github but I'd prefer not to multiply the number of
> organizations involved without good reason. The only reason I've seen
> proposed for github is independence from qpid/ActiveMQ, and a new Apache
> project would satisfy this requirement just as well.
It's a meritocracy. Typically one or a couple of forks in the
community are much more active integrating and merging and stabilizing
the forked contributions. Those folks will typically become the
starting point for new forks since they are the most stable points
with the most features. So in a way it's those active forks which
'decide' what is worthy. If that integration fork ever becomes
stale.. another fork can easily pickup where he left off and take over
the integration duties.
On Fri, Jun 11, 2010 at 11:24 AM, Marnie McCormack
<marnie.m...@googlemail.com> wrote:
> On Fri, Jun 11, 2010 at 3:53 PM, Hiram Chirino <hi...@hiramchirino.com>wrote:
>
>> Picking Github also means picking a more decentralized collaboration
>> model where there is no 'owner' or group of owners that folks have to
>> get blessing from to start contributing in a meaningful way. Any one
>> can fork at any time and contribute. Worthy contributions will be
>> merged by the other forks. That aspect also increases the idea of
>> vendor/organization independence.
>>
> Who decides whats worthy - how would a community like this operate ?
Github = adoption.