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?
