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 <[email protected]> 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 <[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
