?
-Tim
- Original Message -
From: Tom Arnfeld t...@duedil.com
To: dev@mesos.apache.org
Cc: u...@mesos.apache.org
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
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
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/
,
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
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.
I'd planned on having mesos be a submodule. That way, you'll get the
correct protos without any duplication.
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
Embraced language repos is a great path too. +1 for not having to tie
automake into the respective language build systems.
Ensuring that they all work together when Mesos is changing becomes a bit
more difficult, but not worse than CI'ing builds of the respective
bindings against HEAD (is bindings
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
+1, esp re: Go.
Test harness for language bindings will be pretty important.
Cheers,
Tim
- Original Message -
From: Niklas Nielsen nik...@mesosphere.io
To: dev dev@mesos.apache.org
Cc: u...@mesos.apache.org
Sent: Thursday, July 10, 2014 5:57:49 PM
Subject: Re: Mesos language
: *Niklas Nielsen nik...@mesosphere.io
*To: *dev dev@mesos.apache.org
*Cc: *u...@mesos.apache.org
*Sent: *Thursday, July 10, 2014 5:57:49 PM
*Subject: *Re: Mesos language bindings in the wild
I just wanted to clarify - native, meaning _no_ dependency to libmesos and
native to its language (only
Naming suggestion, let's call these pure language bindings. Native is
overloaded.
On Fri, Jul 11, 2014 at 8:40 AM, Niklas Nielsen nik...@mesosphere.io
wrote:
Embraced language repos is a great path too. +1 for not having to tie
automake into the respective language build systems.
Ensuring
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
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,
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
14 matches
Mail list logo
