mesos-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim St Clair <tstcl...@redhat.com>
Subject Re: Mesos language bindings in the wild
Date Tue, 15 Jul 2014 01:44:46 GMT
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" <myanata@msn.com>
> To: user@mesos.apache.org
> 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" <tom@duedil.com>
> >> To: dev@mesos.apache.org
> >> Cc: user@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 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 <thomas@saunter.org> 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 <niklas@mesosphere.io>
> >>>> 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 <dhamon@twopensource.com>
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 <niklas@mesosphere.io>
> >>>>> 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.

Mime
View raw message