So... your response basically capitulates to the fragmentation argument:
"Yes we will have binding strewn about of questionable quality that may, or may not, work with core." The point that I'm trying to make is, fragmentation *is not* a good thing. -------------------------------------- Case in point - The Hadoop Ecosystem (fragmentation) In order for anyone to make a salient stack of any measure, vendors have to knit together components into a stack which can then be consumed by the masses. -------------------------------------- Counterpoint - Spark (curating) libraries Spark bundles 1st order interface libraries as part of a curated core. You are guaranteed that the core will inter-operate, and PySpark is given 1st class standing. -------------------------------------- This is a bad idea, unless there is a plan to hedge the risk. -Tim ----- Original Message ----- > From: "yifan" <[email protected]> > To: [email protected] > Sent: Monday, July 14, 2014 7:10:34 PM > Subject: Re: Mesos language bindings in the wild > > 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 > > -- Cheers, Timothy St. Clair Red Hat Inc.
