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: dev@mesos.apache.org > Cc: u...@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.
