Return-Path: X-Original-To: apmail-mesos-user-archive@www.apache.org Delivered-To: apmail-mesos-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D14161828D for ; Wed, 2 Sep 2015 19:01:50 +0000 (UTC) Received: (qmail 96097 invoked by uid 500); 2 Sep 2015 19:01:47 -0000 Delivered-To: apmail-mesos-user-archive@mesos.apache.org Received: (qmail 96042 invoked by uid 500); 2 Sep 2015 19:01:47 -0000 Mailing-List: contact user-help@mesos.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@mesos.apache.org Delivered-To: mailing list user@mesos.apache.org Received: (qmail 96032 invoked by uid 99); 2 Sep 2015 19:01:47 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Sep 2015 19:01:47 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id B3CF6F0E39 for ; Wed, 2 Sep 2015 19:01:46 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.901 X-Spam-Level: ** X-Spam-Status: No, score=2.901 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=mesosphere.io Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id FIE45G4Modj2 for ; Wed, 2 Sep 2015 19:01:33 +0000 (UTC) Received: from mail-io0-f200.google.com (mail-io0-f200.google.com [209.85.223.200]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 026C521567 for ; Wed, 2 Sep 2015 19:01:33 +0000 (UTC) Received: by ioii196 with SMTP id i196so49613268ioi.3 for ; Wed, 02 Sep 2015 12:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mesosphere.io; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6+m6nGBbmgAp8YiYmT7ZDhj1ixyb604i/KfSIAXqbwA=; b=V6tpaJHeZWeTnG/mk0qskcmSnZa36O9/JvH1IT5IOnb29jp36MoJ/ZOJo0C0pvEpe1 Gt+ghRQnrAI2Z3KZPtRp8kE5/jgXAPI6VmZhmEhgPL+QDTt8EuMyGVdqGDWlIWxXb9Qv +Tq+Gi53/Q45+k+MVXUkeoNzVNFO5ExCMg7Xk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=6+m6nGBbmgAp8YiYmT7ZDhj1ixyb604i/KfSIAXqbwA=; b=QpOa2owYHm4bZwSSz4+b7seHbPFzbHX0usrPjocEdI4lIEtlHEo18X4f8P+WlMuIgi JwcEUG6cyAm/fLGbX3LEtQP+w9FH2INJeQPrONQbzHLJridTfGRWpxZRyBveoD2baUfC k6tek7+CUvI1wIB7wFmkdUTVCOcLTT7VJUQjPR4k/ChvAkE8xxXgPZcMIaFP/bSe2mpy ERzDd67mW6SrzleggHEvej8V4VUkF71wltg99AfVO7Rqu7t1EwAPaakY0ywXjEpIWzR0 xPyfpvEt5cyESgNXQF4ZUWZ57LpcXQGaeiBjWebYuR1ef7hgeaTLLj9N/9f3f4EEPJGb tAxg== X-Gm-Message-State: ALoCoQmSN3279ImVD6NaaeJ7OYJG6q+1zzbhnEXj3b9U0R0G2of43Q7rn+1NZBQ9szDG4ERW0Sf4 X-Received: by 10.182.70.37 with SMTP id j5mr23970286obu.4.1441220491702; Wed, 02 Sep 2015 12:01:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.3.10 with HTTP; Wed, 2 Sep 2015 12:01:12 -0700 (PDT) In-Reply-To: References: From: Artem Harutyunyan Date: Wed, 2 Sep 2015 12:01:12 -0700 Message-ID: Subject: Re: API client libraries To: dev@mesos.apache.org Cc: "user@mesos.apache.org" Content-Type: multipart/alternative; boundary=089e0158b210739265051ec84b22 --089e0158b210739265051ec84b22 Content-Type: text/plain; charset=UTF-8 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 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 : 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. > > Thoughts? > --089e0158b210739265051ec84b22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for bringing this up, Vinod!

We have to make sure that there are reference library implementations fo= r 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 kicksta= rt the process and incubate those libraries. Once the initial implementatio= ns of those libraries are in place we should also make sure to have referen= ce 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 <vinodkone@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<= br> our webpage/docs.

Pros:
--> The PMC/committers won't have the burden to maintain client libr= aries
in languages we don't have expertise in.
--> Gives more control (reviews, releases) and attribution (could live i= n
the author's org's or personal repo) to 3rd party client library au= thors

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 w= ith
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 li= ke
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/#doc= ker-remote-api-client-libraries>:
No official library? Links to 3rd party libs.

GitHub <https://developer.github.com/libraries/>: O= fficial support for
Ruby, .Net, Obj-C. Links to 3rd party libs.

Google <https://developers.google.com/d= iscovery/libraries?hl=3Den>: All
official libraries? No links to 3rd party libs?

K8S <http://kubernetes.io/v1.0/docs/dev= el/client-libraries.html>: Official
support for Go. Links to 3rd party libs.

Twitter <https://dev.twitter.com/overview/a= pi/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/com= mons
repo because the project would be not be officially supporting 3rd party libs. The supported C++ libs will live in the mesos repo.

Thoughts?

--089e0158b210739265051ec84b22--