I've been working on the Java binding of proton-c and have a couple of
questions about how we're naming our various libraries.
On Linux, running "make all" produces the following:
bindings/ruby/cproton.so
bindings/python/_cproton.so
bindings/perl/libcproton_perl.so
bindings/libproton-swig.so (on
Phil,
The only shared-object in that list that is a proper "library" is
libqpid-proton.so. The others are extension modules for their various
scripting languages. I'm not 100% sure, but I believe that the naming
conventions are dictated by the scripting language's extension mechanisms.
-Te
On Fri, Jan 4, 2013 at 11:04 AM, Ted Ross wrote:
> Phil,
>
> The only shared-object in that list that is a proper "library" is
> libqpid-proton.so. The others are extension modules for their various
> scripting languages. I'm not 100% sure, but I believe that the naming
> conventions are dictat
On Thu, Jan 3, 2013 at 7:11 AM, Darryl L. Pierce wrote:
> On Wed, Jan 02, 2013 at 12:54:34PM -0500, Rafael Schloming wrote:
> > > We need to make it a part of the release process to bump the release
> > > number in the following files:
> > >
> > > proton-c/CMakeLists.txt
> > > proton-c/bindings/p
On Fri, Jan 04, 2013 at 11:04:31AM -0500, Ted Ross wrote:
> Phil,
>
> The only shared-object in that list that is a proper "library" is
> libqpid-proton.so. The others are extension modules for their
> various scripting languages. I'm not 100% sure, but I believe that
> the naming conventions ar
On Fri, Jan 04, 2013 at 11:21:07AM -0500, Rafael Schloming wrote:
> > I pushed a patch this morning that bumped the Perl and Ruby versions.
> > Can you please include that in RC2? Thanks.
> >
>
> That will be picked up for RC2, but I really think we need one and only one
> place to bump the versio
Thanks for the responses guys. That all makes sense.
The only change that I'd propose is therefore that the Perl and Java
bindings:
bindings/perl/libcproton_perl.so bindings/java/libproton-swig.so
... should both be renamed to libcproton.so.
Compared to the other bindings, it seems inconsistent
On Fri, Jan 04, 2013 at 07:58:10PM +, Phil Harvey wrote:
> Thanks for the responses guys. That all makes sense.
>
> The only change that I'd propose is therefore that the Perl and Java
> bindings:
>
> bindings/perl/libcproton_perl.so bindings/java/libproton-swig.so
>
> ... should both be ren
On Fri, Jan 4, 2013 at 2:58 PM, Phil Harvey wrote:
> Thanks for the responses guys. That all makes sense.
>
> The only change that I'd propose is therefore that the Perl and Java
> bindings:
>
> bindings/perl/libcproton_perl.so bindings/java/libproton-swig.so
>
> ... should both be renamed to libc
On Fri, Jan 04, 2013 at 03:32:44PM -0500, Rafael Schloming wrote:
> Given what little I know of loading JNI stuff, that seems to make sense for
> Java.
>
> FWIW, the python and ruby bindings don't ever actually expose the name of
> the C extension library since in both cases we have the so-called
On Fri, Jan 4, 2013 at 3:15 PM, Darryl L. Pierce wrote:
> On Fri, Jan 04, 2013 at 07:58:10PM +, Phil Harvey wrote:
> > Thanks for the responses guys. That all makes sense.
> >
> > The only change that I'd propose is therefore that the Perl and Java
> > bindings:
> >
> > bindings/perl/libcprot
On Fri, Jan 4, 2013 at 1:22 PM, Darryl L. Pierce wrote:
> On Fri, Jan 04, 2013 at 11:21:07AM -0500, Rafael Schloming wrote:
> > > I pushed a patch this morning that bumped the Perl and Ruby versions.
> > > Can you please include that in RC2? Thanks.
> > >
> >
> > That will be picked up for RC2, b
Ditto for Java. From the developer's point of view, they'll simply be
using the Java interfaces in proton-api such as Connection [1].
Our current intention is that the choice of whether to use the pure Java
implementations or the proton-c-via-Swig-via-JNI one will be made using a
factory instanti
Does that mean you won't be able to use both the C and Java implementation
simultaneously within a single JVM?
--Rafael
On Fri, Jan 4, 2013 at 4:02 PM, Phil Harvey wrote:
> Ditto for Java. From the developer's point of view, they'll simply be
> using the Java interfaces in proton-api such as Co
The in-progress code on the jni branch does not currently allow this,
although is no technical barrier to doing it. We just haven't yet decided
on the nicest api for allowing the application to choose the implementation
it wants.
The ability to mix implementations within a jvm will certainly be ni
15 matches
Mail list logo