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