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 >>>
