You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Darryl L. Pierce" <dp...@redhat.com> on 2012/02/09 19:38:39 UTC
Non-blocking I/O packaging...
Based on feedback, I've successfully moved the non-blocking I/O
extensions to Qpid out of the public APIs. The APIs now live in a shared
library named libqpidnonblockio and are build below the bindings
directory.
The question I have now is how ought we distribute this library? The
library is only required for a languages whose runtime has a GIL.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Non-blocking I/O packaging...
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Wed, Feb 22, 2012 at 11:56:48AM +0000, Gordon Sim wrote:
> On 02/20/2012 04:18 PM, Darryl L. Pierce wrote:
> >On Thu, Feb 09, 2012 at 01:38:39PM -0500, Darryl L. Pierce wrote:
> >>Based on feedback, I've successfully moved the non-blocking I/O
> >>extensions to Qpid out of the public APIs. The APIs now live in a shared
> >>library named libqpidnonblockio and are build below the bindings
> >>directory.
> >>
> >>The question I have now is how ought we distribute this library? The
> >>library is only required for a languages whose runtime has a GIL.
> >
> >Anybody have an opinion on this? The library itself isn't going to be a
> >part of the public APIs but still needs to be delivered for the Ruby
> >language bindings.
>
> How is the existing C-based binding library for ruby distributed? I
> think at present it's just part of the c++ tarball, right?
The native extensions for Ruby will go out as a gem. We _could_ add into
the gem the additional code to build the actual library file, but I
don't think that's what we should do. Especially if a system is going to
have other language bindings for other apps. Then we'd have multiple
copies of the code rather than sharing the library.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Non-blocking I/O packaging...
Posted by Gordon Sim <gs...@redhat.com>.
On 02/20/2012 04:18 PM, Darryl L. Pierce wrote:
> On Thu, Feb 09, 2012 at 01:38:39PM -0500, Darryl L. Pierce wrote:
>> Based on feedback, I've successfully moved the non-blocking I/O
>> extensions to Qpid out of the public APIs. The APIs now live in a shared
>> library named libqpidnonblockio and are build below the bindings
>> directory.
>>
>> The question I have now is how ought we distribute this library? The
>> library is only required for a languages whose runtime has a GIL.
>
> Anybody have an opinion on this? The library itself isn't going to be a
> part of the public APIs but still needs to be delivered for the Ruby
> language bindings.
How is the existing C-based binding library for ruby distributed? I
think at present it's just part of the c++ tarball, right?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Non-blocking I/O packaging...
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Thu, Feb 09, 2012 at 01:38:39PM -0500, Darryl L. Pierce wrote:
> Based on feedback, I've successfully moved the non-blocking I/O
> extensions to Qpid out of the public APIs. The APIs now live in a shared
> library named libqpidnonblockio and are build below the bindings
> directory.
>
> The question I have now is how ought we distribute this library? The
> library is only required for a languages whose runtime has a GIL.
Anybody have an opinion on this? The library itself isn't going to be a
part of the public APIs but still needs to be delivered for the Ruby
language bindings.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/