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 <vinodk...@apache.org> 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? >
