mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From yifan <>
Subject Re: Mesos language bindings in the wild
Date Sat, 12 Jul 2014 09:07:11 GMT
Hey guys, I am very excited to see this going!
Vote +1 for splitting things. Totally agree with Tom Arnfeld as for Go 
they have some common way to import packages.
And as I know there are very good tools for package version control in 
Go (e.g. godep), so I don't worry about that.

But except for the protobuf, we will also need a language binding for 
zookeeper to implement the detector.

I am not sure with the status of those language bindings, but for Go, I 
am sure we cannot include it in 3rd party if we want to
distribute the native bindings in AL2, because the go binding for 
zookeeper is is under LGPL.


On 07/11/2014 08:40 AM, Dominic Hamon wrote:
> 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
> It's not meant to be anything but an
> API test-case.
> On Fri, Jul 11, 2014 at 8:22 AM, Tom Arnfeld <> 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 "" 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 <> wrote:
>>> I've started preparing the python bindings to hopefully take this
>>> route ( would love some reviews!
>>> ). In fact, there is already a native python implementation of both
>>> libprocess and the framework apis! (
>>> , ).
>>> 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 <>
>> 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 <>
>>>>> 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 <>
>>>>> 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
>>>>> start
>>>>>> collaborating with you on your current work.
>>>>>> We are interested to hear what thoughts you all might have on this.
>>>>>> Thanks,
>>>>>> Niklas

Gu Yifan

View raw message