I could also help with reference implementation (be it Go, Java, Scala/Akka or Python - i prefer Go as large part of our infrastructure is written in Go).
In my opinion, externalizing client libraries is good way to go - leave Mesos as core C++ project and move Java and Python clients to separate repos - i think it will also motivate more people to contribute (especially those scared with C++ code :)). For the C++ part - Mesos is actually the first project that really motivates me to get my rusty C++ skills up to date :). I think there must be some coordination from Mesos core team as ideally there should be one client API for every most used/important language that is kept up to date and its core contributors should be aware about further Mesos directions/changes - it will need support especially in the beginning. I will try to be awake for community sync - but the time is brutal - for me it is 1 am CET :(. 2015-09-03 21:17 GMT+02:00 Steven Schlansker <[email protected]>: > As a Mesos user who wants to be more of a contributor but hates C++, I > could volunteer to help work with the Java reference implementation. > > I totally understand wanting to keep the various client libraries out of > the Mesos release cycle and somewhat independent. Maybe a model where the > clients are not "officially" part of the Mesos project, but are instead > simply blessed as being the reference implementations, makes the most sense > to start with. We can always merge them in later if a compelling reason > shows up. > > On Sep 2, 2015, at 12:01 PM, Artem Harutyunyan <[email protected]> > wrote: > > > Thanks for bringing this up, Vinod! > > > > We have to make sure that there are reference library implementations > for at least Python, Java, and Go. They may end up being owned and > maintained by the community, but I feel that Mesos developers should at > least kickstart the process and incubate those libraries. Once the initial > implementations of those libraries are in place we should also make sure to > have reference usage examples for them (like we do right now with Rendler). > > > > In any case, this is a very important topic so I will go ahead and add > it to tomorrow's community sync agenda. > > > > Cheers, > > Artem. > > > > On Wed, Sep 2, 2015 at 11:49 AM, Vinod Kone <[email protected]> > wrote: > > Hi folks, > > > > Now that the v1 scheduler HTTP API (beta) is on the verge of being > > released, I wanted to open up the discussion about client libraries for > the > > API. Mainly around support and home for the libs. > > > > One idea is that, going forward, the only supported client library would > be > > C++ library which will live in the mesos repo. All other client libraries > > (java, python, go etc) will not be officially supported but linked to > from > > our webpage/docs. > > > > Pros: > > --> The PMC/committers won't have the burden to maintain client libraries > > in languages we don't have expertise in. > > --> Gives more control (reviews, releases) and attribution (could live in > > the author's org's or personal repo) to 3rd party client library authors > > > > Cons: > > --> Might be a step backward because we would be officially dropping > > support for Java and Python. This is probably a good thing? > > --> No quality control of the libraries by the PMC. Need co-ordination > with > > library authors to incorporate API changes. Could lead to bad user > > experience. > > > > I've taken a quick look at what other major projects do and it looks like > > most of them officially support a few api libs and then link to 3rdparty > > libs. > > > > Docker > > < > https://docs.docker.com/reference/api/remote_api_client_libraries/#docker-remote-api-client-libraries > >: > > No official library? Links to 3rd party libs. > > > > GitHub <https://developer.github.com/libraries/>: Official support for > > Ruby, .Net, Obj-C. Links to 3rd party libs. > > > > Google <https://developers.google.com/discovery/libraries?hl=en>: All > > official libraries? No links to 3rd party libs? > > > > K8S <http://kubernetes.io/v1.0/docs/devel/client-libraries.html>: > Official > > support for Go. Links to 3rd party libs. > > > > Twitter <https://dev.twitter.com/overview/api/twitter-libraries>: > Official > > support for Java. Links to 3rd party libs. > > > > > > Is this the way we want to go? This does mean we won't need a > mesos/commons > > repo because the project would be not be officially supporting 3rd party > > libs. The supported C++ libs will live in the mesos repo. > > > > Thoughts? > > > >
