So I fear the fragmentation that can occur if we provide native bindings 
outside of the core, unless there is some mechanism for testing, & a well 
established versioning scheme. 

IMHO, priority inversion on 'versioning' should come before bindings to ensure 
we adhere to policy.    

Thoughts? 

-Tim


----- Original Message -----
> From: "Tom Arnfeld" <t...@duedil.com>
> To: d...@mesos.apache.org
> Cc: user@mesos.apache.org
> Sent: Friday, July 11, 2014 10:22:59 AM
> Subject: Re: Mesos language bindings in the wild
> 
> Very exciting. I'd vote +1 for splitting them out. Especially if you
> look at the common way of using Go imports, just stick the project on
> GitHub and import it directly using "github.com/mesos/mesos-go" or
> similar.
> 
> I guess one argument is that you have more fragmentation of the code
> (e.g every library has it's own copy of the protos) but I'm not sure
> that's a bad thing.
> 
> Just my two cents. Looking forward to this!
> 
> > On 11 Jul 2014, at 16:59, Thomas Rampelberg <tho...@saunter.org> wrote:
> >
> > I've started preparing the python bindings to hopefully take this
> > route ( https://reviews.apache.org/r/23224/ would love some reviews!
> > ). In fact, there is already a native python implementation of both
> > libprocess and the framework apis! (https://github.com/wickman/pesos/
> > , https://github.com/wickman/compactor ).
> >
> > What are the benefits of bindings being part of the project source
> > itself instead of having blessed implementations like mesos-python
> > where the source and versioning becomes separate? I've been running
> > into difficulties making automake and python's build tools play nicely
> > together. It seems like there'd be more flexibility in general by
> > splitting them out.
> >
> >
> >> On Thu, Jul 10, 2014 at 3:57 PM, Niklas Nielsen <nik...@mesosphere.io>
> >> wrote:
> >> I just wanted to clarify - native, meaning _no_ dependency to libmesos and
> >> native to its language (only Go, only Python and so on) i.e. use the
> >> low-level API.
> >>
> >> Sorry for the confusion,
> >> Niklas
> >>
> >>
> >>> On 10 July 2014 15:55, Dominic Hamon <dha...@twopensource.com> wrote:
> >>>
> >>> In my dream world, we wouldn't need any native bindings. I can imagine
> >>> having example frameworks or starter frameworks that use the low-level
> >>> API
> >>> (the wire protocol with protocol buffers for message passing), but
> >>> nothing
> >>> like we have that needs C or JNI, etc.
> >>>
> >>>
> >>>
> >>>
> >>> On Thu, Jul 10, 2014 at 3:26 PM, Niklas Nielsen <nik...@mesosphere.io>
> >>> wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> I wanted to start a discussion around the language bindings in the wild
> >>>> (Go, Haskell, native Python, Go, Java and so on) and possibly get to a
> >>>> strategy where we start bringing those into Mesos proper. As most things
> >>>> points towards, it will probably make sense to focus on the native
> >>>> "bindings" leveraging the low-level API. To name one candidate to start
> >>>> with, we are especially interested in getting Go native support in Mesos
> >>>> proper (and in a solid state). So Vladimir, we'd be super thrilled to
> >>> start
> >>>> collaborating with you on your current work.
> >>>>
> >>>> We are interested to hear what thoughts you all might have on this.
> >>>>
> >>>> Thanks,
> >>>> Niklas
> >>>
> 

-- 
Cheers,
Timothy St. Clair
Red Hat Inc.

Reply via email to