Hi Tim,
I found that in zookeeper, they also separate the bindings from the core.
https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZKClientBindings
So, IMHO, I think it should be the maintainer's responsibility to keep
the binding in healthy state, with clear documentation of which version
of the mesos core they supports.
Yifan
On 07/14/2014 11:30 AM, Tim St Clair wrote:
So I fear the fragmentation that can occur if we provide native bindings outside of
the core, unless there is some mechanism for testing, & a well established
versioning scheme.
IMHO, priority inversion on 'versioning' should come before bindings to ensure
we adhere to policy.
Thoughts?
-Tim
----- Original Message -----
From: "Tom Arnfeld" <[email protected]>
To: [email protected]
Cc: [email protected]
Sent: Friday, July 11, 2014 10:22:59 AM
Subject: Re: Mesos language bindings in the wild
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 <[email protected]> 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 <[email protected]>
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 <[email protected]> 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 <[email protected]>
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
