[HTTP API] Client Libraries

[Anand Mazumdar]

Hi,

We recently committed documentation around available client libraries for the 
Scheduler 
/Executor
  HTTP 
API’s. 

Link to doc: 
https://github.com/apache/mesos/blob/master/docs/api-client-libraries.md 
 

It would be great if folks can send a PR or review to add more implementations 
that they maintain/use.

-anand

Re: API client libraries

[Steven Schlansker]

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 <ar...@mesosphere.io> 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> 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?
> 

Re: API client libraries

[Ondrej Smola]

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 <sschlans...@opentable.com>:

> 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 <ar...@mesosphere.io>
> 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>
> 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?
> >
>
>

API client libraries

[Vinod Kone]

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?

Re: API client libraries

[Artem Harutyunyan]

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

Re: API client libraries

[Vinod Kone]

On Wed, Sep 2, 2015 at 11:49 AM, Vinod Kone  wrote:

> --> Might be a step backward because we would be officially dropping
> support for Java and Python. This is probably a good thing?
>

s/officially dropping support/dropping official support/

Re: API client libraries

[CCAAT]

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