I wrote a Clojure binding that uses reflection ( https://github.com/dgrnbrg/clj-mesos) -- I think that most of the dynamic langs could use something like this to reduce the pain of building a binding against a specific version. I ended up writing a simple rule-system to generate the appropriate static/dynamic marshaller for each protobuf, based on its naming convention and type.
On Fri, Jul 11, 2014 at 8:48 PM, Tim St Clair <[email protected]> wrote: > +1, esp re: Go. > > Test harness for language bindings will be pretty important. > > Cheers, > Tim > > ------------------------------ > > *From: *"Niklas Nielsen" <[email protected]> > *To: *"dev" <[email protected]> > *Cc: *[email protected] > *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 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 >> > >> > > > > > -- > Cheers, > Timothy St. Clair > Red Hat Inc. >
