mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From yifan <myan...@msn.com>
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.
https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZKClientBindings

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.
(http://www.apache.org/legal/3party.html#category-x)


Yifan

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
> 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 <tom@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 <thomas@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 <niklas@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 <dhamon@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 <niklas@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


-- 
Gu Yifan


Mime
View raw message