@ Vinod:: An excellent idea as the code bases mature. It will force
clear delineation of functionality and allow those 'other language"
experts to define their codes for Mesos more clearly.
@ Artem:: Another excellent point. The mesos "core team" will have to
still work with the other language/module teams to define things and
debug some codes that use core interfaces, API and common
inter-operative constructs.
Furthermore this sort of code maturity will set the stage for other
languages to bring enhanced functionality to Mesos.
Last, Separating the C/C++ will facilitate those efforts to run mesos
as close as possible to 'bare metal' on a variety of processors, gpus
and memory-types (RDMA) which are all available now with GCC-5.x This
effort will most like result in tremendous performance boosting of Mesos
and all the companion codes.
A smashingly outstanding idea!!!!
James
On 09/02/2015 02:01 PM, Artem Harutyunyan 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 <vinodk...@apache.org
<mailto: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?
