You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Bruce Snyder <br...@gmail.com> on 2010/06/10 16:18:09 UTC
Fwd: AMQP client library collaboration
Forgot to CC the Qpid dev list.
---------- Forwarded message ----------
From: Bruce Snyder <br...@gmail.com>
Date: Wed, Jun 9, 2010 at 8:44 PM
Subject: AMQP client library collaboration
To: dev@activemq.apache.org
This week I spent a couple days at the AMQP face-to-face meeting in
San Diego (http://www.amqp.org/confluence/display/AMQP/2010+Face-to-Face).
Not only have I learned a lot about AMQP 1.0, but I also found that
some of the Qpid guys are interested in collaboration. The idea that
was suggested was a collaborative effort to create AMQP core client
libraries for C, Java and .NET to be used to create AMQP clients so
that we are not each reinventing the wheel. These libraries could then
be used by the ActiveMQ and Qpid projects (and possibly others) for
creating their own AMQP custom clients with custom features for each
broker implementation (without the need to worry about implementing
all the necessary handling for the core AMQP spec).
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).
I'm interested in such collaboration but I'd like to know if others
are as well.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Hiram Chirino <hi...@hiramchirino.com>.
BTW.. I do hope that once the project gets established and stabilizes,
we take the time to re-evaluate if the community that has formed is
large and diverse enough to thrive in as an Apache standalone
project... and then at that time figure out how to bring it back..
perhaps into qpid.
On Thu, Jun 10, 2010 at 1:18 PM, Bruce Snyder <br...@gmail.com> wrote:
> On Thu, Jun 10, 2010 at 4:07 PM, Marnie McCormack
> <ma...@googlemail.com> wrote:
>> Hi Bruce,
>> Sounds a really interesting idea, and potentially a good combination of
>> product/knowledge and people for a core AMQP 1.0 implementation.
>>
>> Can I ask why not use the ASF as we do for contribution to the Qpid/ActiveMQ
>> code base now, is there a reason why people won't want to contribute the
>> code to the ASF ?
>>
>> If we're not using the ASF, then it'd be best to agree the license that the
>> code'll be under right from the start I think ?
>
> Since the ASF doesn't provide infrastructure yet for generic project
> hosting, we would need to host the project either under the ActiveMQ
> project or the Qpid project and that's not really appropriate for
> something that is meant to be completely separate from those two.
> Also, we want to encourage non-ASF folks to participate more easily.
> This is what lead Rafi and I just loosely agree that Github would be
> more appropriate (especially git makes it so easy to contribute and
> fork). But the lack of a project mailing list is one problem with
> Github. But as Hiram pointed out in his reply, perhaps Github + Google
> Groups = the correct combination.
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 6:00 PM, Hiram Chirino <hi...@hiramchirino.com> wrote:
> I personally think that the incubator is one of the worst places to
> build a project/community. Apache has recognized this.. that's why
> there's Apache Labs. The incubator works when you have an existing
> project and are working towards transitioning it to a full fledged
> project.
I tend to agree, especially after having gone through the experience
of the Incubator three times now.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Hiram Chirino <hi...@hiramchirino.com>.
I personally think that the incubator is one of the worst places to
build a project/community. Apache has recognized this.. that's why
there's Apache Labs. The incubator works when you have an existing
project and are working towards transitioning it to a full fledged
project.
On Thu, Jun 10, 2010 at 1:48 PM, Bruce Snyder <br...@gmail.com> wrote:
> On Thu, Jun 10, 2010 at 5:39 PM, Robert Godfrey <ro...@gmail.com> wrote:
>> On 10 June 2010 19:18, Bruce Snyder <br...@gmail.com> wrote:
>>> On Thu, Jun 10, 2010 at 4:07 PM, Marnie McCormack
>>> <ma...@googlemail.com> wrote:
>>>> Hi Bruce,
>>>> Sounds a really interesting idea, and potentially a good combination of
>>>> product/knowledge and people for a core AMQP 1.0 implementation.
>>>>
>>>> Can I ask why not use the ASF as we do for contribution to the Qpid/ActiveMQ
>>>> code base now, is there a reason why people won't want to contribute the
>>>> code to the ASF ?
>>>>
>>>> If we're not using the ASF, then it'd be best to agree the license that the
>>>> code'll be under right from the start I think ?
>>>
>>> Since the ASF doesn't provide infrastructure yet for generic project
>>> hosting, we would need to host the project either under the ActiveMQ
>>> project or the Qpid project and that's not really appropriate for
>>> something that is meant to be completely separate from those two.
>>> Also, we want to encourage non-ASF folks to participate more easily.
>>> This is what lead Rafi and I just loosely agree that Github would be
>>> more appropriate (especially git makes it so easy to contribute and
>>> fork). But the lack of a project mailing list is one problem with
>>> Github. But as Hiram pointed out in his reply, perhaps Github + Google
>>> Groups = the correct combination.
>>
>> Yeah - I'm very happy with that combination - and agree that is
>> probably the best approach
>>
>> If, down the road, we think it should become an Apache Project (via
>> the incubator) we can go down that road...
>>
>> Obviously in that case we'd want to keep track of contributors as well
>> as using the ASL
>
> OK, so the two options for creating the project that are currently on
> the table are:
>
> 1) Github + Google Groups
>
> 2) Apache Incubator
>
> My initial bias would be toward #1 simply because I prefer git over
> svn. But as I think about, we should not overlook the Incubator.
>
> <devil's-advocate>
> If we intend to eventually bring the project back to the ASF, why not
> just start a new project in the Incubator now? We can put together a
> proposal that includes all the folks who want to be involved and just
> be very inclusive about voting in new folks. After all, it's really up
> to the project PMC about how high we set the bar for committership and
> PMC membership. The PMC runs the project using the Apache Way and is
> as inclusive as it wants to be.
> </devil's-advocate>
>
> As I type out my thoughts on this, I am liking this option more and
> more. But my observations of the Incubator over the last several years
> are definitely clouded by the problems it has had.
>
> Thoughts, opinions?
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by David Jencks <da...@yahoo.com>.
On Jun 10, 2010, at 10:48 AM, Bruce Snyder wrote:
> On Thu, Jun 10, 2010 at 5:39 PM, Robert Godfrey <ro...@gmail.com> wrote:
>> On 10 June 2010 19:18, Bruce Snyder <br...@gmail.com> wrote:
>>> On Thu, Jun 10, 2010 at 4:07 PM, Marnie McCormack
>>> <ma...@googlemail.com> wrote:
>>>> Hi Bruce,
>>>> Sounds a really interesting idea, and potentially a good combination of
>>>> product/knowledge and people for a core AMQP 1.0 implementation.
>>>>
>>>> Can I ask why not use the ASF as we do for contribution to the Qpid/ActiveMQ
>>>> code base now, is there a reason why people won't want to contribute the
>>>> code to the ASF ?
>>>>
>>>> If we're not using the ASF, then it'd be best to agree the license that the
>>>> code'll be under right from the start I think ?
>>>
>>> Since the ASF doesn't provide infrastructure yet for generic project
>>> hosting, we would need to host the project either under the ActiveMQ
>>> project or the Qpid project and that's not really appropriate for
>>> something that is meant to be completely separate from those two.
>>> Also, we want to encourage non-ASF folks to participate more easily.
>>> This is what lead Rafi and I just loosely agree that Github would be
>>> more appropriate (especially git makes it so easy to contribute and
>>> fork). But the lack of a project mailing list is one problem with
>>> Github. But as Hiram pointed out in his reply, perhaps Github + Google
>>> Groups = the correct combination.
>>
>> Yeah - I'm very happy with that combination - and agree that is
>> probably the best approach
>>
>> If, down the road, we think it should become an Apache Project (via
>> the incubator) we can go down that road...
>>
>> Obviously in that case we'd want to keep track of contributors as well
>> as using the ASL
>
> OK, so the two options for creating the project that are currently on
> the table are:
>
> 1) Github + Google Groups
>
> 2) Apache Incubator
>
> My initial bias would be toward #1 simply because I prefer git over
> svn. But as I think about, we should not overlook the Incubator.
>
> <devil's-advocate>
> If we intend to eventually bring the project back to the ASF, why not
> just start a new project in the Incubator now? We can put together a
> proposal that includes all the folks who want to be involved and just
> be very inclusive about voting in new folks. After all, it's really up
> to the project PMC about how high we set the bar for committership and
> PMC membership. The PMC runs the project using the Apache Way and is
> as inclusive as it wants to be.
> </devil's-advocate>
>
> As I type out my thoughts on this, I am liking this option more and
> more. But my observations of the Incubator over the last several years
> are definitely clouded by the problems it has had.
>
> Thoughts, opinions?
I think you are greatly overestimating the problems an incubator project that has several experienced apache committers actively involved would face graduating. I also think you are underestimating the utility to potential users of having paid attention to and documented IP issues, which seems to me the main annoyance working at apache brings.
thanks
david jencks
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 5:39 PM, Robert Godfrey <ro...@gmail.com> wrote:
> On 10 June 2010 19:18, Bruce Snyder <br...@gmail.com> wrote:
>> On Thu, Jun 10, 2010 at 4:07 PM, Marnie McCormack
>> <ma...@googlemail.com> wrote:
>>> Hi Bruce,
>>> Sounds a really interesting idea, and potentially a good combination of
>>> product/knowledge and people for a core AMQP 1.0 implementation.
>>>
>>> Can I ask why not use the ASF as we do for contribution to the Qpid/ActiveMQ
>>> code base now, is there a reason why people won't want to contribute the
>>> code to the ASF ?
>>>
>>> If we're not using the ASF, then it'd be best to agree the license that the
>>> code'll be under right from the start I think ?
>>
>> Since the ASF doesn't provide infrastructure yet for generic project
>> hosting, we would need to host the project either under the ActiveMQ
>> project or the Qpid project and that's not really appropriate for
>> something that is meant to be completely separate from those two.
>> Also, we want to encourage non-ASF folks to participate more easily.
>> This is what lead Rafi and I just loosely agree that Github would be
>> more appropriate (especially git makes it so easy to contribute and
>> fork). But the lack of a project mailing list is one problem with
>> Github. But as Hiram pointed out in his reply, perhaps Github + Google
>> Groups = the correct combination.
>
> Yeah - I'm very happy with that combination - and agree that is
> probably the best approach
>
> If, down the road, we think it should become an Apache Project (via
> the incubator) we can go down that road...
>
> Obviously in that case we'd want to keep track of contributors as well
> as using the ASL
OK, so the two options for creating the project that are currently on
the table are:
1) Github + Google Groups
2) Apache Incubator
My initial bias would be toward #1 simply because I prefer git over
svn. But as I think about, we should not overlook the Incubator.
<devil's-advocate>
If we intend to eventually bring the project back to the ASF, why not
just start a new project in the Incubator now? We can put together a
proposal that includes all the folks who want to be involved and just
be very inclusive about voting in new folks. After all, it's really up
to the project PMC about how high we set the bar for committership and
PMC membership. The PMC runs the project using the Apache Way and is
as inclusive as it wants to be.
</devil's-advocate>
As I type out my thoughts on this, I am liking this option more and
more. But my observations of the Incubator over the last several years
are definitely clouded by the problems it has had.
Thoughts, opinions?
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 5:39 PM, Robert Godfrey <ro...@gmail.com> wrote:
> On 10 June 2010 19:18, Bruce Snyder <br...@gmail.com> wrote:
>> On Thu, Jun 10, 2010 at 4:07 PM, Marnie McCormack
>> <ma...@googlemail.com> wrote:
>>> Hi Bruce,
>>> Sounds a really interesting idea, and potentially a good combination of
>>> product/knowledge and people for a core AMQP 1.0 implementation.
>>>
>>> Can I ask why not use the ASF as we do for contribution to the Qpid/ActiveMQ
>>> code base now, is there a reason why people won't want to contribute the
>>> code to the ASF ?
>>>
>>> If we're not using the ASF, then it'd be best to agree the license that the
>>> code'll be under right from the start I think ?
>>
>> Since the ASF doesn't provide infrastructure yet for generic project
>> hosting, we would need to host the project either under the ActiveMQ
>> project or the Qpid project and that's not really appropriate for
>> something that is meant to be completely separate from those two.
>> Also, we want to encourage non-ASF folks to participate more easily.
>> This is what lead Rafi and I just loosely agree that Github would be
>> more appropriate (especially git makes it so easy to contribute and
>> fork). But the lack of a project mailing list is one problem with
>> Github. But as Hiram pointed out in his reply, perhaps Github + Google
>> Groups = the correct combination.
>
> Yeah - I'm very happy with that combination - and agree that is
> probably the best approach
>
> If, down the road, we think it should become an Apache Project (via
> the incubator) we can go down that road...
>
> Obviously in that case we'd want to keep track of contributors as well
> as using the ASL
OK, so the two options for creating the project that are currently on
the table are:
1) Github + Google Groups
2) Apache Incubator
My initial bias would be toward #1 simply because I prefer git over
svn. But as I think about, we should not overlook the Incubator.
<devil's-advocate>
If we intend to eventually bring the project back to the ASF, why not
just start a new project in the Incubator now? We can put together a
proposal that includes all the folks who want to be involved and just
be very inclusive about voting in new folks. After all, it's really up
to the project PMC about how high we set the bar for committership and
PMC membership. The PMC runs the project using the Apache Way and is
as inclusive as it wants to be.
</devil's-advocate>
As I type out my thoughts on this, I am liking this option more and
more. But my observations of the Incubator over the last several years
are definitely clouded by the problems it has had.
Thoughts, opinions?
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Robert Godfrey <ro...@gmail.com>.
On 10 June 2010 19:18, Bruce Snyder <br...@gmail.com> wrote:
> On Thu, Jun 10, 2010 at 4:07 PM, Marnie McCormack
> <ma...@googlemail.com> wrote:
>> Hi Bruce,
>> Sounds a really interesting idea, and potentially a good combination of
>> product/knowledge and people for a core AMQP 1.0 implementation.
>>
>> Can I ask why not use the ASF as we do for contribution to the Qpid/ActiveMQ
>> code base now, is there a reason why people won't want to contribute the
>> code to the ASF ?
>>
>> If we're not using the ASF, then it'd be best to agree the license that the
>> code'll be under right from the start I think ?
>
> Since the ASF doesn't provide infrastructure yet for generic project
> hosting, we would need to host the project either under the ActiveMQ
> project or the Qpid project and that's not really appropriate for
> something that is meant to be completely separate from those two.
> Also, we want to encourage non-ASF folks to participate more easily.
> This is what lead Rafi and I just loosely agree that Github would be
> more appropriate (especially git makes it so easy to contribute and
> fork). But the lack of a project mailing list is one problem with
> Github. But as Hiram pointed out in his reply, perhaps Github + Google
> Groups = the correct combination.
Yeah - I'm very happy with that combination - and agree that is
probably the best approach
If, down the road, we think it should become an Apache Project (via
the incubator) we can go down that road...
Obviously in that case we'd want to keep track of contributors as well
as using the ASL
-- Rob
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Hiram Chirino <hi...@hiramchirino.com>.
BTW.. I do hope that once the project gets established and stabilizes,
we take the time to re-evaluate if the community that has formed is
large and diverse enough to thrive in as an Apache standalone
project... and then at that time figure out how to bring it back..
perhaps into qpid.
On Thu, Jun 10, 2010 at 1:18 PM, Bruce Snyder <br...@gmail.com> wrote:
> On Thu, Jun 10, 2010 at 4:07 PM, Marnie McCormack
> <ma...@googlemail.com> wrote:
>> Hi Bruce,
>> Sounds a really interesting idea, and potentially a good combination of
>> product/knowledge and people for a core AMQP 1.0 implementation.
>>
>> Can I ask why not use the ASF as we do for contribution to the Qpid/ActiveMQ
>> code base now, is there a reason why people won't want to contribute the
>> code to the ASF ?
>>
>> If we're not using the ASF, then it'd be best to agree the license that the
>> code'll be under right from the start I think ?
>
> Since the ASF doesn't provide infrastructure yet for generic project
> hosting, we would need to host the project either under the ActiveMQ
> project or the Qpid project and that's not really appropriate for
> something that is meant to be completely separate from those two.
> Also, we want to encourage non-ASF folks to participate more easily.
> This is what lead Rafi and I just loosely agree that Github would be
> more appropriate (especially git makes it so easy to contribute and
> fork). But the lack of a project mailing list is one problem with
> Github. But as Hiram pointed out in his reply, perhaps Github + Google
> Groups = the correct combination.
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Lahiru Gunathilake <gl...@gmail.com>.
On Thu, Jun 10, 2010 at 10:48 PM, Bruce Snyder <br...@gmail.com>wrote:
> On Thu, Jun 10, 2010 at 4:07 PM, Marnie McCormack
> <ma...@googlemail.com> wrote:
> > Hi Bruce,
> > Sounds a really interesting idea, and potentially a good combination of
> > product/knowledge and people for a core AMQP 1.0 implementation.
> >
> > Can I ask why not use the ASF as we do for contribution to the
> Qpid/ActiveMQ
> > code base now, is there a reason why people won't want to contribute the
> > code to the ASF ?
> >
> > If we're not using the ASF, then it'd be best to agree the license that
> the
> > code'll be under right from the start I think ?
>
> Since the ASF doesn't provide infrastructure yet for generic project
> hosting, we would need to host the project either under the ActiveMQ
> project or the Qpid project and that's not really appropriate for
> something that is meant to be completely separate from those two.
> Also, we want to encourage non-ASF folks to participate more easily.
>
+1, but this is not the whole point of a project(get the participation of
non-ASF people), we need to make sure we have a quality with the
implementation and we should have scope and control in the project.
Lahiru
> This is what lead Rafi and I just loosely agree that Github would be
> more appropriate (especially git makes it so easy to contribute and
> fork). But the lack of a project mailing list is one problem with
> Github. But as Hiram pointed out in his reply, perhaps Github + Google
> Groups = the correct combination.
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Apache Qpid, Worlds dominant messaging middleware..!!!
Senior Software Engineer
WSO2 Inc
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 6:05 PM, Paul Fremantle <pz...@gmail.com> wrote:
> Bruce
>
> 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.
Hi Paul! I thought of too, but Labs is only for folks who are already
committers, so it's a no go.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 6:05 PM, Paul Fremantle <pz...@gmail.com> wrote:
> Bruce
>
> 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.
Hi Paul! I thought of too, but Labs is only for folks who are already
committers, so it's a no go.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Paul Fremantle <pz...@gmail.com>.
Bruce
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.
Paul
On Thu, Jun 10, 2010 at 6:18 PM, Bruce Snyder <br...@gmail.com> wrote:
> On Thu, Jun 10, 2010 at 4:07 PM, Marnie McCormack
> <ma...@googlemail.com> wrote:
>> Hi Bruce,
>> Sounds a really interesting idea, and potentially a good combination of
>> product/knowledge and people for a core AMQP 1.0 implementation.
>>
>> Can I ask why not use the ASF as we do for contribution to the Qpid/ActiveMQ
>> code base now, is there a reason why people won't want to contribute the
>> code to the ASF ?
>>
>> If we're not using the ASF, then it'd be best to agree the license that the
>> code'll be under right from the start I think ?
>
> Since the ASF doesn't provide infrastructure yet for generic project
> hosting, we would need to host the project either under the ActiveMQ
> project or the Qpid project and that's not really appropriate for
> something that is meant to be completely separate from those two.
> Also, we want to encourage non-ASF folks to participate more easily.
> This is what lead Rafi and I just loosely agree that Github would be
> more appropriate (especially git makes it so easy to contribute and
> fork). But the lack of a project mailing list is one problem with
> Github. But as Hiram pointed out in his reply, perhaps Github + Google
> Groups = the correct combination.
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Paul Fremantle <pz...@gmail.com>.
Bruce
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.
Paul
On Thu, Jun 10, 2010 at 6:18 PM, Bruce Snyder <br...@gmail.com> wrote:
> On Thu, Jun 10, 2010 at 4:07 PM, Marnie McCormack
> <ma...@googlemail.com> wrote:
>> Hi Bruce,
>> Sounds a really interesting idea, and potentially a good combination of
>> product/knowledge and people for a core AMQP 1.0 implementation.
>>
>> Can I ask why not use the ASF as we do for contribution to the Qpid/ActiveMQ
>> code base now, is there a reason why people won't want to contribute the
>> code to the ASF ?
>>
>> If we're not using the ASF, then it'd be best to agree the license that the
>> code'll be under right from the start I think ?
>
> Since the ASF doesn't provide infrastructure yet for generic project
> hosting, we would need to host the project either under the ActiveMQ
> project or the Qpid project and that's not really appropriate for
> something that is meant to be completely separate from those two.
> Also, we want to encourage non-ASF folks to participate more easily.
> This is what lead Rafi and I just loosely agree that Github would be
> more appropriate (especially git makes it so easy to contribute and
> fork). But the lack of a project mailing list is one problem with
> Github. But as Hiram pointed out in his reply, perhaps Github + Google
> Groups = the correct combination.
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 4:07 PM, Marnie McCormack
<ma...@googlemail.com> wrote:
> Hi Bruce,
> Sounds a really interesting idea, and potentially a good combination of
> product/knowledge and people for a core AMQP 1.0 implementation.
>
> Can I ask why not use the ASF as we do for contribution to the Qpid/ActiveMQ
> code base now, is there a reason why people won't want to contribute the
> code to the ASF ?
>
> If we're not using the ASF, then it'd be best to agree the license that the
> code'll be under right from the start I think ?
Since the ASF doesn't provide infrastructure yet for generic project
hosting, we would need to host the project either under the ActiveMQ
project or the Qpid project and that's not really appropriate for
something that is meant to be completely separate from those two.
Also, we want to encourage non-ASF folks to participate more easily.
This is what lead Rafi and I just loosely agree that Github would be
more appropriate (especially git makes it so easy to contribute and
fork). But the lack of a project mailing list is one problem with
Github. But as Hiram pointed out in his reply, perhaps Github + Google
Groups = the correct combination.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 4:07 PM, Marnie McCormack
<ma...@googlemail.com> wrote:
> Hi Bruce,
> Sounds a really interesting idea, and potentially a good combination of
> product/knowledge and people for a core AMQP 1.0 implementation.
>
> Can I ask why not use the ASF as we do for contribution to the Qpid/ActiveMQ
> code base now, is there a reason why people won't want to contribute the
> code to the ASF ?
>
> If we're not using the ASF, then it'd be best to agree the license that the
> code'll be under right from the start I think ?
Since the ASF doesn't provide infrastructure yet for generic project
hosting, we would need to host the project either under the ActiveMQ
project or the Qpid project and that's not really appropriate for
something that is meant to be completely separate from those two.
Also, we want to encourage non-ASF folks to participate more easily.
This is what lead Rafi and I just loosely agree that Github would be
more appropriate (especially git makes it so easy to contribute and
fork). But the lack of a project mailing list is one problem with
Github. But as Hiram pointed out in his reply, perhaps Github + Google
Groups = the correct combination.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi Bruce,
Sounds a really interesting idea, and potentially a good combination of
product/knowledge and people for a core AMQP 1.0 implementation.
Can I ask why not use the ASF as we do for contribution to the Qpid/ActiveMQ
code base now, is there a reason why people won't want to contribute the
code to the ASF ?
If we're not using the ASF, then it'd be best to agree the license that the
code'll be under right from the start I think ?
Regards,
Marnie
On Thu, Jun 10, 2010 at 3:18 PM, Bruce Snyder <br...@gmail.com>wrote:
> Forgot to CC the Qpid dev list.
>
>
> ---------- Forwarded message ----------
> From: Bruce Snyder <br...@gmail.com>
> Date: Wed, Jun 9, 2010 at 8:44 PM
> Subject: AMQP client library collaboration
> To: dev@activemq.apache.org
>
>
> This week I spent a couple days at the AMQP face-to-face meeting in
> San Diego (http://www.amqp.org/confluence/display/AMQP/2010+Face-to-Face).
> Not only have I learned a lot about AMQP 1.0, but I also found that
> some of the Qpid guys are interested in collaboration. The idea that
> was suggested was a collaborative effort to create AMQP core client
> libraries for C, Java and .NET to be used to create AMQP clients so
> that we are not each reinventing the wheel. These libraries could then
> be used by the ActiveMQ and Qpid projects (and possibly others) for
> creating their own AMQP custom clients with custom features for each
> broker implementation (without the need to worry about implementing
> all the necessary handling for the core AMQP spec).
>
> 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).
>
> I'm interested in such collaboration but I'd like to know if others
> are as well.
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder
>
>
>
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 5:21 PM, Rajith Attapattu <ra...@gmail.com> wrote:
> On Thu, Jun 10, 2010 at 1:17 PM, Lahiru Gunathilake <gl...@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
>> !
>
> This effort needs to be vendor neutral to encourage participation from
> a wider audience, as such it's not appropriate to host in under Qpid
> or ActiveMQ.
+1 Rajith.
Please make sure to keep CC'ing both the ActiveMQ dev list and the
Qpid dev list so that everyone sees all replies.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
Re: AMQP client library collaboration
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Jun 10, 2010 at 8:43 PM, Carl Trieloff <cc...@redhat.com> wrote:
> On 06/10/2010 01:21 PM, Rajith Attapattu wrote:
>>
>> This effort needs to be vendor neutral to encourage participation from
>> a wider audience, as such it's not appropriate to host in under Qpid
>> or ActiveMQ.
>>
>
> Apache is vendor neutral!\
Carl I used the wrong word here. I should have used "independent of
any broker implementation" instead of "vendor neutral".
>
> Carl.
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@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-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Carl Trieloff <cc...@redhat.com>.
On 06/10/2010 01:21 PM, Rajith Attapattu wrote:
> This effort needs to be vendor neutral to encourage participation from
> a wider audience, as such it's not appropriate to host in under Qpid
> or ActiveMQ.
>
Apache is vendor neutral!
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 8:28 PM, Steve Huston <sh...@riverace.com> wrote:
...
> Ideally it would be great to get participation from other
> AMQP-implementing groups as well.
I believe we are all in agreement on that point.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Fri, Jun 11, 2010 at 7:01 AM, Rajith Attapattu <ra...@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.
Rajith's points are excellent and speak to the spirit of this entire
idea. I encourage everyone to re-read them.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
Re: AMQP client library collaboration
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Fri, Jun 11, 2010 at 9:17 AM, Marnie McCormack
<ma...@googlemail.com> wrote:
> The starting point for this discussion centred on the development of core
> libraries that the Qpid/ActiveMQ projects could use for 1-0. (Clearly I'm
> interested in how this might work for the Qpid implementation of AMQP.)
>
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 2:01 PM, Rajith Attapattu <ra...@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 <ro...@gmail.com>
>> wrote:
>> > On 11 June 2010 08:48, Bruce Snyder <br...@gmail.com> wrote:
>> >> On Thu, Jun 10, 2010 at 8:54 PM, Marnie McCormack
>> >> <ma...@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-subscribe@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-subscribe@qpid.apache.org
>>
>>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: AMQP client library collaboration
Posted by Jonathan Robie <jo...@redhat.com>.
On Fri, 2010-06-11 at 09:41 -0400, Steve Huston wrote:
> Hi Marnie,
>
> > The starting point for this discussion centred on the
> > development of core libraries that the Qpid/ActiveMQ projects
> > could use for 1-0. (Clearly I'm interested in how this might
> > work for the Qpid implementation of AMQP.)
>
> I think the main benefit from such an effort across projects would be a
> common, agreed _API_ for a AMQP client across a number of languages. An
> implementation would be extra points, but I could see the different
> projects all implementing it differently as well.
A common API would be extremely beneficial. I would love to see that
happen, and that's something I think Qpid should support. I think the
new APIs for C++ and Python might also be a useful starting point in
this direction.
For clarity: in my earlier email, I was not taking a position one way or
another, just asking questions about what the goals are.
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: AMQP client library collaboration
Posted by Steve Huston <sh...@riverace.com>.
Hi Marnie,
> The starting point for this discussion centred on the
> development of core libraries that the Qpid/ActiveMQ projects
> could use for 1-0. (Clearly I'm interested in how this might
> work for the Qpid implementation of AMQP.)
I think the main benefit from such an effort across projects would be a
common, agreed _API_ for a AMQP client across a number of languages. An
implementation would be extra points, but I could see the different
projects all implementing it differently as well.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Marnie McCormack <ma...@googlemail.com>.
The starting point for this discussion centred on the development of core
libraries that the Qpid/ActiveMQ projects could use for 1-0. (Clearly I'm
interested in how this might work for the Qpid implementation of AMQP.)
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.
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.
Marnie
On Fri, Jun 11, 2010 at 2:01 PM, Rajith Attapattu <ra...@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 <ro...@gmail.com>
> wrote:
> > On 11 June 2010 08:48, Bruce Snyder <br...@gmail.com> wrote:
> >> On Thu, Jun 10, 2010 at 8:54 PM, Marnie McCormack
> >> <ma...@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-subscribe@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-subscribe@qpid.apache.org
>
>
Re: AMQP client library collaboration
Posted by Andrew Stitcher <as...@redhat.com>.
On Fri, 2010-06-11 at 09:09 -0400, Hiram Chirino wrote:
> BTW, I've created the mailing list on google groups that was suggested
> on earlier posts:
>
> 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.
>
There is one blocking issue (at least for me) in using google groups -
I'm am not going to create another online account just to join a mailing
list. I'm sure that all of you that already use google mail will not
have this issue.
But I already have somewhere in excess of 20 online identities and I'm
not going to create a new one just so I can join a single mailing list.
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Fri, Jun 11, 2010 at 7:09 AM, Hiram Chirino <hi...@hiramchirino.com> wrote:
> BTW, I've created the mailing list on google groups that was suggested
> on earlier posts:
>
> 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.
Thanks for doing this, Hiram. I was going to do exactly this earlier
today but I've been hung up with something.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Fri, Jun 11, 2010 at 7:09 AM, Hiram Chirino <hi...@hiramchirino.com> wrote:
> BTW, I've created the mailing list on google groups that was suggested
> on earlier posts:
>
> 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.
Thanks for doing this, Hiram. I was going to do exactly this earlier
today but I've been hung up with something.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
Re: AMQP client library collaboration
Posted by Hiram Chirino <hi...@hiramchirino.com>.
BTW, I've created the mailing list on google groups that was suggested
on earlier posts:
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 <ra...@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 <ro...@gmail.com> wrote:
>> On 11 June 2010 08:48, Bruce Snyder <br...@gmail.com> wrote:
>>> On Thu, Jun 10, 2010 at 8:54 PM, Marnie McCormack
>>> <ma...@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-subscribe@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-subscribe@qpid.apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Fri, Jun 11, 2010 at 7:01 AM, Rajith Attapattu <ra...@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.
Rajith's points are excellent and speak to the spirit of this entire
idea. I encourage everyone to re-read them.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Hiram Chirino <hi...@hiramchirino.com>.
BTW, I've created the mailing list on google groups that was suggested
on earlier posts:
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 <ra...@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 <ro...@gmail.com> wrote:
>> On 11 June 2010 08:48, Bruce Snyder <br...@gmail.com> wrote:
>>> On Thu, Jun 10, 2010 at 8:54 PM, Marnie McCormack
>>> <ma...@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-subscribe@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-subscribe@qpid.apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Rajith Attapattu <ra...@gmail.com>.
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 <ro...@gmail.com> wrote:
> On 11 June 2010 08:48, Bruce Snyder <br...@gmail.com> wrote:
>> On Thu, Jun 10, 2010 at 8:54 PM, Marnie McCormack
>> <ma...@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-subscribe@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-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Robert Godfrey <ro...@gmail.com>.
On 11 June 2010 08:48, Bruce Snyder <br...@gmail.com> wrote:
> On Thu, Jun 10, 2010 at 8:54 PM, Marnie McCormack
> <ma...@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-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Marnie McCormack <ma...@googlemail.com>.
On Fri, Jun 11, 2010 at 7:48 AM, Bruce Snyder <br...@gmail.com>wrote:
> On Thu, Jun 10, 2010 at 8:54 PM, Marnie McCormack
> <ma...@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.
>
>
I don't really follow the logic here - I'm not suggesting where the project
would go (under Qpid or ActiveMQ) but we're talking about open source
development and yet you seem to be suggesting the Apache projects are
somehow proprietary - which they are clearly not. What would be the problem
with having the AMQP core libraries associated with an Apache project ?
> > 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.
>
>
Again, don't understand the issue with being associated with an open source
AMQP impl.
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 8:54 PM, Marnie McCormack
<ma...@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.
> 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.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 8:54 PM, Marnie McCormack
<ma...@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.
> 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.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
Re: AMQP client library collaboration
Posted by Rob Davies <ra...@gmail.com>.
This does sound weird - really not sure what this has to do with
ActiveMQ
On 10 Jun 2010, at 21:54, Marnie McCormack <marnie.mccormack@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 ?
>
> 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 ?
>
> Regards,
> Marnie
>
>
> On Thu, Jun 10, 2010 at 9:28 PM, Steve Huston <sh...@riverace.com>
> wrote:
>
>>> -----Original Message-----
>>> From: Gordon Sim [mailto:gsim@redhat.com]
>>> Sent: Thursday, June 10, 2010 3:38 PM
>>> To: dev@qpid.apache.org
>>> Cc: dev@activemq.apache.org
>>> Subject: Re: AMQP client library collaboration
>>>
>>>
>>> On 06/10/2010 06:57 PM, Bruce Snyder wrote:
>>>> On Thu, Jun 10, 2010 at 5:50 PM, Gordon Sim<gs...@redhat.com>
>>>> wrote:
>>>>> On 06/10/2010 06:21 PM, Rajith Attapattu wrote:
>>>>>>
>>>>>> This effort needs to be vendor neutral to encourage participation
>>>>>> from a wider audience, as such it's not appropriate to
>>> host in under
>>>>>> Qpid or ActiveMQ.
>>>>>
>>>>> What do you mean by 'vendor neutral'? How are either Qpid
>>> or ActiveMQ
>>>>> 'vendors'? They are surely open source projects,
>>> collaborations that
>>>>> both aim to be as inclusive as possible.
>>>>
>>>> Good point, Gordon ;-). Well, I guess my thought is that
>>> because each
>>>> project will provide a broker implementation of the AMQP spec that
>>>> neither is appropriate for a neutral protocol level client
>>> that is not
>>>> specific to either broker. The Apache Commons HTTP Client
>>> could have
>>>> been hosted as a subproject to the HTTPD server project, but that
>>>> wasn't appropriate so it was made a separate project. The
>>> same logic
>>>> applies in this case.
>>>
>>> I would respectfully disagree. The httpd project started
>>> specifically as
>>> a web server (not a browser, not a generic client). The Qpid
>>> project was
>>> specifically started as a place for collaborating on multi
>>> language AMQP
>>> implementations (including but not restricted to broker code).
>>>
>>> Qpid should be open and inclusive, if it is not perceived as such we
>>> want to change that. What is it that makes 'neutrality' an issue,
>>> especially between two Apache projects?
>>
>> Ideally it would be great to get participation from other
>> AMQP-implementing groups as well.
>>
>> -Steve
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Marnie McCormack <ma...@googlemail.com>.
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 ?
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 ?
Regards,
Marnie
On Thu, Jun 10, 2010 at 9:28 PM, Steve Huston <sh...@riverace.com> wrote:
> > -----Original Message-----
> > From: Gordon Sim [mailto:gsim@redhat.com]
> > Sent: Thursday, June 10, 2010 3:38 PM
> > To: dev@qpid.apache.org
> > Cc: dev@activemq.apache.org
> > Subject: Re: AMQP client library collaboration
> >
> >
> > On 06/10/2010 06:57 PM, Bruce Snyder wrote:
> > > On Thu, Jun 10, 2010 at 5:50 PM, Gordon Sim<gs...@redhat.com> wrote:
> > >> On 06/10/2010 06:21 PM, Rajith Attapattu wrote:
> > >>>
> > >>> This effort needs to be vendor neutral to encourage participation
> > >>> from a wider audience, as such it's not appropriate to
> > host in under
> > >>> Qpid or ActiveMQ.
> > >>
> > >> What do you mean by 'vendor neutral'? How are either Qpid
> > or ActiveMQ
> > >> 'vendors'? They are surely open source projects,
> > collaborations that
> > >> both aim to be as inclusive as possible.
> > >
> > > Good point, Gordon ;-). Well, I guess my thought is that
> > because each
> > > project will provide a broker implementation of the AMQP spec that
> > > neither is appropriate for a neutral protocol level client
> > that is not
> > > specific to either broker. The Apache Commons HTTP Client
> > could have
> > > been hosted as a subproject to the HTTPD server project, but that
> > > wasn't appropriate so it was made a separate project. The
> > same logic
> > > applies in this case.
> >
> > I would respectfully disagree. The httpd project started
> > specifically as
> > a web server (not a browser, not a generic client). The Qpid
> > project was
> > specifically started as a place for collaborating on multi
> > language AMQP
> > implementations (including but not restricted to broker code).
> >
> > Qpid should be open and inclusive, if it is not perceived as such we
> > want to change that. What is it that makes 'neutrality' an issue,
> > especially between two Apache projects?
>
> Ideally it would be great to get participation from other
> AMQP-implementing groups as well.
>
> -Steve
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 8:28 PM, Steve Huston <sh...@riverace.com> wrote:
...
> Ideally it would be great to get participation from other
> AMQP-implementing groups as well.
I believe we are all in agreement on that point.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 7:37 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 06/10/2010 06:57 PM, Bruce Snyder wrote:
>>
>> On Thu, Jun 10, 2010 at 5:50 PM, Gordon Sim<gs...@redhat.com> wrote:
>>>
>>> On 06/10/2010 06:21 PM, Rajith Attapattu wrote:
>>>>
>>>> This effort needs to be vendor neutral to encourage participation from
>>>> a wider audience, as such it's not appropriate to host in under Qpid
>>>> or ActiveMQ.
>>>
>>> What do you mean by 'vendor neutral'? How are either Qpid or ActiveMQ
>>> 'vendors'? They are surely open source projects, collaborations that both
>>> aim to be as inclusive as possible.
>>
>> Good point, Gordon ;-). Well, I guess my thought is that because each
>> project will provide a broker implementation of the AMQP spec that
>> neither is appropriate for a neutral protocol level client that is not
>> specific to either broker. The Apache Commons HTTP Client could have
>> been hosted as a subproject to the HTTPD server project, but that
>> wasn't appropriate so it was made a separate project. The same logic
>> applies in this case.
>
> I would respectfully disagree. The httpd project started specifically as a
> web server (not a browser, not a generic client). The Qpid project was
> specifically started as a place for collaborating on multi language AMQP
> implementations (including but not restricted to broker code).
>
> Qpid should be open and inclusive, if it is not perceived as such we want to
> change that. What is it that makes 'neutrality' an issue, especially between
> two Apache projects?
I doubt that folks from other AMQP broker impls would come to the Qpid
project to work on a client. That's the point.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 7:37 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 06/10/2010 06:57 PM, Bruce Snyder wrote:
>>
>> On Thu, Jun 10, 2010 at 5:50 PM, Gordon Sim<gs...@redhat.com> wrote:
>>>
>>> On 06/10/2010 06:21 PM, Rajith Attapattu wrote:
>>>>
>>>> This effort needs to be vendor neutral to encourage participation from
>>>> a wider audience, as such it's not appropriate to host in under Qpid
>>>> or ActiveMQ.
>>>
>>> What do you mean by 'vendor neutral'? How are either Qpid or ActiveMQ
>>> 'vendors'? They are surely open source projects, collaborations that both
>>> aim to be as inclusive as possible.
>>
>> Good point, Gordon ;-). Well, I guess my thought is that because each
>> project will provide a broker implementation of the AMQP spec that
>> neither is appropriate for a neutral protocol level client that is not
>> specific to either broker. The Apache Commons HTTP Client could have
>> been hosted as a subproject to the HTTPD server project, but that
>> wasn't appropriate so it was made a separate project. The same logic
>> applies in this case.
>
> I would respectfully disagree. The httpd project started specifically as a
> web server (not a browser, not a generic client). The Qpid project was
> specifically started as a place for collaborating on multi language AMQP
> implementations (including but not restricted to broker code).
>
> Qpid should be open and inclusive, if it is not perceived as such we want to
> change that. What is it that makes 'neutrality' an issue, especially between
> two Apache projects?
I doubt that folks from other AMQP broker impls would come to the Qpid
project to work on a client. That's the point.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Carl Trieloff <cc...@redhat.com>.
On 06/10/2010 04:28 PM, Steve Huston wrote:
>> Qpid should be open and inclusive, if it is not perceived as such we
>> > want to change that. What is it that makes 'neutrality' an issue,
>> > especially between two Apache projects?
>>
> Ideally it would be great to get participation from other
> AMQP-implementing groups as well.
>
+1
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: AMQP client library collaboration
Posted by Steve Huston <sh...@riverace.com>.
> -----Original Message-----
> From: Gordon Sim [mailto:gsim@redhat.com]
> Sent: Thursday, June 10, 2010 3:38 PM
> To: dev@qpid.apache.org
> Cc: dev@activemq.apache.org
> Subject: Re: AMQP client library collaboration
>
>
> On 06/10/2010 06:57 PM, Bruce Snyder wrote:
> > On Thu, Jun 10, 2010 at 5:50 PM, Gordon Sim<gs...@redhat.com> wrote:
> >> On 06/10/2010 06:21 PM, Rajith Attapattu wrote:
> >>>
> >>> This effort needs to be vendor neutral to encourage participation
> >>> from a wider audience, as such it's not appropriate to
> host in under
> >>> Qpid or ActiveMQ.
> >>
> >> What do you mean by 'vendor neutral'? How are either Qpid
> or ActiveMQ
> >> 'vendors'? They are surely open source projects,
> collaborations that
> >> both aim to be as inclusive as possible.
> >
> > Good point, Gordon ;-). Well, I guess my thought is that
> because each
> > project will provide a broker implementation of the AMQP spec that
> > neither is appropriate for a neutral protocol level client
> that is not
> > specific to either broker. The Apache Commons HTTP Client
> could have
> > been hosted as a subproject to the HTTPD server project, but that
> > wasn't appropriate so it was made a separate project. The
> same logic
> > applies in this case.
>
> I would respectfully disagree. The httpd project started
> specifically as
> a web server (not a browser, not a generic client). The Qpid
> project was
> specifically started as a place for collaborating on multi
> language AMQP
> implementations (including but not restricted to broker code).
>
> Qpid should be open and inclusive, if it is not perceived as such we
> want to change that. What is it that makes 'neutrality' an issue,
> especially between two Apache projects?
Ideally it would be great to get participation from other
AMQP-implementing groups as well.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Gordon Sim <gs...@redhat.com>.
On 06/10/2010 06:57 PM, Bruce Snyder wrote:
> On Thu, Jun 10, 2010 at 5:50 PM, Gordon Sim<gs...@redhat.com> wrote:
>> On 06/10/2010 06:21 PM, Rajith Attapattu wrote:
>>>
>>> This effort needs to be vendor neutral to encourage participation from
>>> a wider audience, as such it's not appropriate to host in under Qpid
>>> or ActiveMQ.
>>
>> What do you mean by 'vendor neutral'? How are either Qpid or ActiveMQ
>> 'vendors'? They are surely open source projects, collaborations that both
>> aim to be as inclusive as possible.
>
> Good point, Gordon ;-). Well, I guess my thought is that because each
> project will provide a broker implementation of the AMQP spec that
> neither is appropriate for a neutral protocol level client that is not
> specific to either broker. The Apache Commons HTTP Client could have
> been hosted as a subproject to the HTTPD server project, but that
> wasn't appropriate so it was made a separate project. The same logic
> applies in this case.
I would respectfully disagree. The httpd project started specifically as
a web server (not a browser, not a generic client). The Qpid project was
specifically started as a place for collaborating on multi language AMQP
implementations (including but not restricted to broker code).
Qpid should be open and inclusive, if it is not perceived as such we
want to change that. What is it that makes 'neutrality' an issue,
especially between two Apache projects?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 5:50 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 06/10/2010 06:21 PM, Rajith Attapattu wrote:
>>
>> This effort needs to be vendor neutral to encourage participation from
>> a wider audience, as such it's not appropriate to host in under Qpid
>> or ActiveMQ.
>
> What do you mean by 'vendor neutral'? How are either Qpid or ActiveMQ
> 'vendors'? They are surely open source projects, collaborations that both
> aim to be as inclusive as possible.
Good point, Gordon ;-). Well, I guess my thought is that because each
project will provide a broker implementation of the AMQP spec that
neither is appropriate for a neutral protocol level client that is not
specific to either broker. The Apache Commons HTTP Client could have
been hosted as a subproject to the HTTPD server project, but that
wasn't appropriate so it was made a separate project. The same logic
applies in this case.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Robert Godfrey <ro...@gmail.com>.
On 10 June 2010 19:50, Gordon Sim <gs...@redhat.com> wrote:
> On 06/10/2010 06:21 PM, Rajith Attapattu wrote:
>>
>> This effort needs to be vendor neutral to encourage participation from
>> a wider audience, as such it's not appropriate to host in under Qpid
>> or ActiveMQ.
>
> What do you mean by 'vendor neutral'? How are either Qpid or ActiveMQ
> 'vendors'? They are surely open source projects, collaborations that both
> aim to be as inclusive as possible.
I think that the case for not hosting this in either ActiveMQ or Qpid
is that this effort is not actually targeted at wither of these
projects specifically... It is a project in itself to work on a useful
building block for AMQP1-0 implementations. ActiveMQ and/or Qpid may
later choose to use this, as may any other project wanting to use
AMQP1-0. Hosting within either of the existing projects may obscure
the purpose of this effort and confuse people in believing that the
work is associated with a particular broker/client.
Vendor independence really means not being hosted on a site operated
by one of the vendors involved. Apache (via incubator or otherwise)
clearly fulfills this criterion
-- Rob
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Jun 10, 2010 at 1:50 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 06/10/2010 06:21 PM, Rajith Attapattu wrote:
>>
>> This effort needs to be vendor neutral to encourage participation from
>> a wider audience, as such it's not appropriate to host in under Qpid
>> or ActiveMQ.
>
> What do you mean by 'vendor neutral'? How are either Qpid or ActiveMQ
> 'vendors'? They are surely open source projects, collaborations that both
> aim to be as inclusive as possible.
>
I guess 'vendor' was probably not the best choice of words here.
I think Rob Godfrey explained more or less what I wanted to convey.
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@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-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 5:50 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 06/10/2010 06:21 PM, Rajith Attapattu wrote:
>>
>> This effort needs to be vendor neutral to encourage participation from
>> a wider audience, as such it's not appropriate to host in under Qpid
>> or ActiveMQ.
>
> What do you mean by 'vendor neutral'? How are either Qpid or ActiveMQ
> 'vendors'? They are surely open source projects, collaborations that both
> aim to be as inclusive as possible.
Good point, Gordon ;-). Well, I guess my thought is that because each
project will provide a broker implementation of the AMQP spec that
neither is appropriate for a neutral protocol level client that is not
specific to either broker. The Apache Commons HTTP Client could have
been hosted as a subproject to the HTTPD server project, but that
wasn't appropriate so it was made a separate project. The same logic
applies in this case.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
Re: AMQP client library collaboration
Posted by Gordon Sim <gs...@redhat.com>.
On 06/10/2010 06:21 PM, Rajith Attapattu wrote:
> This effort needs to be vendor neutral to encourage participation from
> a wider audience, as such it's not appropriate to host in under Qpid
> or ActiveMQ.
What do you mean by 'vendor neutral'? How are either Qpid or ActiveMQ
'vendors'? They are surely open source projects, collaborations that
both aim to be as inclusive as possible.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Lahiru Gunathilake <gl...@gmail.com>.
On Thu, Jun 10, 2010 at 10:51 PM, Rajith Attapattu <ra...@gmail.com>wrote:
> On Thu, Jun 10, 2010 at 1:17 PM, Lahiru Gunathilake <gl...@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
> > !
>
> This effort needs to be vendor neutral to encourage participation from
> a wider audience, as such it's not appropriate to host in under Qpid
> or ActiveMQ.
>
+1, so we can start it as a separate project in incubator or we can start
out-side and once the project mature we can move it in to incubator by
giving committership to the people who have contributed !
Lahiru
>
> >
> > Regards
> > Lahiru
> >
> >>
> >> I'm interested in such collaboration but I'd like to know if others
> >> are as well.
> >>
> >> Bruce
> >> --
> >> perl -e 'print
> >> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> >> );'
> >>
> >> ActiveMQ in Action: http://bit.ly/2je6cQ
> >> Blog: http://bruceblog.org/
> >> Twitter: http://twitter.com/brucesnyder
> >>
> >>
> >>
> >> --
> >> perl -e 'print
> >> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> >> );'
> >>
> >> ActiveMQ in Action: http://bit.ly/2je6cQ
> >> Blog: http://bruceblog.org/
> >> Twitter: http://twitter.com/brucesnyder
> >>
> >> ---------------------------------------------------------------------
> >> Apache Qpid - AMQP Messaging Implementation
> >> Project: http://qpid.apache.org
> >> Use/Interact: mailto:dev-subscribe@qpid.apache.org
> >>
> >>
> >
> >
> > --
> > Apache Qpid, Worlds dominant messaging middleware..!!!
> >
> > Senior Software Engineer
> > WSO2 Inc
> >
>
>
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> http://rajith.2rlabs.com/
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Apache Qpid, Worlds dominant messaging middleware..!!!
Senior Software Engineer
WSO2 Inc
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 5:21 PM, Rajith Attapattu <ra...@gmail.com> wrote:
> On Thu, Jun 10, 2010 at 1:17 PM, Lahiru Gunathilake <gl...@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
>> !
>
> This effort needs to be vendor neutral to encourage participation from
> a wider audience, as such it's not appropriate to host in under Qpid
> or ActiveMQ.
+1 Rajith.
Please make sure to keep CC'ing both the ActiveMQ dev list and the
Qpid dev list so that everyone sees all replies.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Jun 10, 2010 at 1:17 PM, Lahiru Gunathilake <gl...@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
> !
This effort needs to be vendor neutral to encourage participation from
a wider audience, as such it's not appropriate to host in under Qpid
or ActiveMQ.
>
> Regards
> Lahiru
>
>>
>> I'm interested in such collaboration but I'd like to know if others
>> are as well.
>>
>> Bruce
>> --
>> perl -e 'print
>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>> );'
>>
>> ActiveMQ in Action: http://bit.ly/2je6cQ
>> Blog: http://bruceblog.org/
>> Twitter: http://twitter.com/brucesnyder
>>
>>
>>
>> --
>> perl -e 'print
>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>> );'
>>
>> ActiveMQ in Action: http://bit.ly/2je6cQ
>> Blog: http://bruceblog.org/
>> Twitter: http://twitter.com/brucesnyder
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>
>
> --
> Apache Qpid, Worlds dominant messaging middleware..!!!
>
> Senior Software Engineer
> WSO2 Inc
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Jonathan Robie <jo...@redhat.com>.
On Thu, 2010-06-10 at 17:36 +0000, Bruce Snyder wrote:
> 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.
Would a "spec-focused client library" be a low-level library that uses
APIs more like the ones we used before the new high-level API, or more
like the high level API that we have moved to?
Would this project start with a brand new implementation of the AMQP
clients libraries? How would this implementation be different from the
existing Qpid libraries? Or would you propose that the current Qpid
client library code be moved to a new project?
I would hope that our client libraries will work with any AMQP 1.0
broker. Is the real goal to ensure interop for the client libraries?
Would it be helpful to design an interop testing framework that uses
these clients to test any broker for compatibility?
I wonder if we might need a project for interop testing more than a
separate project for client libraries.
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Hi Marnie,
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
<ma...@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 ?
>
>
>
>> On Fri, Jun 11, 2010 at 10:15 AM, Alan Conway <ac...@redhat.com> wrote:
>> > On 06/10/2010 01:36 PM, Bruce Snyder wrote:
>> >>
>> >> On Thu, Jun 10, 2010 at 5:25 PM, Bruce Snyder<br...@gmail.com>
>> >> wrote:
>> >>>
>> >>> On Thu, Jun 10, 2010 at 5:17 PM, Lahiru Gunathilake<gl...@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.
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > Apache Qpid - AMQP Messaging Implementation
>> > Project: http://qpid.apache.org
>> > Use/Interact: mailto:dev-subscribe@qpid.apache.org
>> >
>> >
>>
>>
>>
>> --
>> Regards,
>> Hiram
>>
>> Blog: http://hiramchirino.com
>>
>> Open Source SOA
>> http://fusesource.com/
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Marnie McCormack <ma...@googlemail.com>.
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 ?
> On Fri, Jun 11, 2010 at 10:15 AM, Alan Conway <ac...@redhat.com> wrote:
> > On 06/10/2010 01:36 PM, Bruce Snyder wrote:
> >>
> >> On Thu, Jun 10, 2010 at 5:25 PM, Bruce Snyder<br...@gmail.com>
> >> wrote:
> >>>
> >>> On Thu, Jun 10, 2010 at 5:17 PM, Lahiru Gunathilake<gl...@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.
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > Apache Qpid - AMQP Messaging Implementation
> > Project: http://qpid.apache.org
> > Use/Interact: mailto:dev-subscribe@qpid.apache.org
> >
> >
>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://fusesource.com/
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: AMQP client library collaboration
Posted by Hiram Chirino <hi...@hiramchirino.com>.
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.
On Fri, Jun 11, 2010 at 10:15 AM, Alan Conway <ac...@redhat.com> wrote:
> On 06/10/2010 01:36 PM, Bruce Snyder wrote:
>>
>> On Thu, Jun 10, 2010 at 5:25 PM, Bruce Snyder<br...@gmail.com>
>> wrote:
>>>
>>> On Thu, Jun 10, 2010 at 5:17 PM, Lahiru Gunathilake<gl...@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.
>
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Alan Conway <ac...@redhat.com>.
On 06/10/2010 01:36 PM, Bruce Snyder wrote:
> On Thu, Jun 10, 2010 at 5:25 PM, Bruce Snyder<br...@gmail.com> wrote:
>> On Thu, Jun 10, 2010 at 5:17 PM, Lahiru Gunathilake<gl...@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.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 5:25 PM, Bruce Snyder <br...@gmail.com> wrote:
> On Thu, Jun 10, 2010 at 5:17 PM, Lahiru Gunathilake <gl...@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.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 5:25 PM, Bruce Snyder <br...@gmail.com> wrote:
> On Thu, Jun 10, 2010 at 5:17 PM, Lahiru Gunathilake <gl...@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.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 5:17 PM, Lahiru Gunathilake <gl...@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.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
Re: AMQP client library collaboration
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 10, 2010 at 5:17 PM, Lahiru Gunathilake <gl...@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.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: AMQP client library collaboration
Posted by Lahiru Gunathilake <gl...@gmail.com>.
>
> 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
!
Regards
Lahiru
>
> I'm interested in such collaboration but I'd like to know if others
> are as well.
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder
>
>
>
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Apache Qpid, Worlds dominant messaging middleware..!!!
Senior Software Engineer
WSO2 Inc