mesos-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Kone <>
Subject API client libraries
Date Wed, 02 Sep 2015 18:49:57 GMT
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.

--> 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

--> 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

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

No official library? Links to 3rd party libs.

GitHub <>: Official support for
Ruby, .Net, Obj-C. Links to 3rd party libs.

Google <>: All
official libraries? No links to 3rd party libs?

K8S <>: Official
support for Go. Links to 3rd party libs.

Twitter <>: 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.


View raw message