I'm a fan of splitting these things out as you end up with various implementations, some of which will be more suited for some applications that others. It also encourages exploration of the API in various ways.
As an aside, I've been playing with a go version too at https://github.com/dominichamon/gozer. It's not meant to be anything but an API test-case. On Fri, Jul 11, 2014 at 8:22 AM, Tom Arnfeld <t...@duedil.com> wrote: > 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 > >>> >
