Mailing-List: contact dev-help@tajo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@tajo.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAM=XDd8UU7MBUTpDev69vdWv_eJEhZSJP8EVTFpQLgAKFfeHDg@mail.gmail.com>
References: 
 <CAM=XDd9mR8kW0iO57U_4vc=NnmX1XPNTxMeZSUbyJdSHA6BVQg@mail.gmail.com>
 <CAM=XDd80H7WWOAs2ADnRhfMK0k1Q8dhiBbk-CrBt7FCZ6w7T-g@mail.gmail.com>
 <CACZfFK5EfMSBQ4ZojuG3B=QbVyOA5W3iLjE_D1SrWk5bY869Aw@mail.gmail.com>
 <CAMrLSE4tOGgQ8P2f43eBGyUe3ZYuLoyVDdYBCUsfMgivFQ2AWA@mail.gmail.com>
 <CAH=F5dn4gabPF1a0azUwUGZG5+kjGhcaJBW=LcMHPZtrSo_p4w@mail.gmail.com>
 <CAM5pAExMa5fyAA9AMx3d9MeGZ170iNiykmCtvQD-RSWUzftWUg@mail.gmail.com>
 <CAEj1Ex700+sepBJBVOm68sNQjNqiwmF23MrbSDEOduueQTF-tQ@mail.gmail.com>
 <CANpXwBBsZYUYr4X+p9TYRYq1vo+qZ0Y2XH3a36OXsPCd0ftvQw@mail.gmail.com>
 <CAM=XDd8UU7MBUTpDev69vdWv_eJEhZSJP8EVTFpQLgAKFfeHDg@mail.gmail.com>
From: Dongjoon Hyun <dongjoon@apache.org>
Date: Fri, 13 Mar 2015 08:40:38 +0900
Message-ID: 
 <CAFu6yH0DgBVwQNbYW3Hrp-6DVzP4fg65MNpuEQqGWUoQ_x_Siw@mail.gmail.com>
Subject: Re: [DISCUSSION] Portable remote client APIs
To: "dev@tajo.apache.org" <dev@tajo.apache.org>
Content-Type: multipart/alternative; boundary=089e0115f0487a58c605111fea81

--089e0115f0487a58c605111fea81
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I give +1 to REST API, too.

Best regards,
Dongjoon.


On Fri, Mar 13, 2015 at 8:34 AM, Hyunsik Choi <hyunsik@apache.org> wrote:

> We seem to get a consent to use REST API. I'll wait for one more day,
> and then we can decide this issue.
>
> Best regards,
> Hyunsik
>
> On Thu, Mar 12, 2015 at 7:56 AM, Hyoungjun Kim <babokim@gmail.com> wrote:
> > Hi all,
> >
> > I give +1 to REST API.
> > I think REST is more common.
> >
> > Warm regards,
> > Hyoungjun
> > 2015. 3. 12. =EC=98=A4=ED=9B=84 10:41=EC=97=90 "Jihun Kang" <ykrips@gma=
il.com>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1:
> >
> >> Hello All,
> >>
> >> I would give +1 to REST API Implementation. Even Protobuf and Thrift
> give
> >> flexibility and extensibility to programmers, but entry barriers for
> these
> >> frameworks are extremely high. Also, if we want to make another client
> >> implementation for other programming languages, we need to figure out
> that
> >> these framework have code generator feature for that programming
> language.
> >>
> >> 2015-03-12 20:18 GMT+09:00 Jaehwa Jung <blrunner@apache.org>:
> >>
> >> > Hi guys
> >> >
> >> > +1 for Hyunsik's suggestion.
> >> >
> >> > REST API may be more efficient for code maintenance and various
> clients
> >> > implementation.
> >> >
> >> > Cheers
> >> > Jaehwa
> >> >  +1 RESTful API for code maintenance
> >> >
> >> > -Jinho
> >> > Best regards
> >> >
> >> > 2015-03-12 17:56 GMT+09:00 CharSyam <charsyam@gmail.com>:
> >> >
> >> > > +1
> >> > >
> >> > > I also agree with hyunsik's suggesttion.
> >> > > I think it is better to make language binding to use Rest API.
> >> > > It will be more efficient and less effort :)
> >> > >
> >> > > 2015-03-12 17:38 GMT+09:00 Jihoon Son <jihoonson@apache.org>:
> >> > >
> >> > > > +1 for Hyunsik's suggestion.
> >> > > > I totally agree with you.
> >> > > >
> >> > > > Warm regards,
> >> > > > Jihoon
> >> > > > 2015=EB=85=84 3=EC=9B=94 12=EC=9D=BC (=EB=AA=A9) =EC=98=A4=ED=9B=
=84 5:35, Hyunsik Choi <hyunsik@apache.org>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=
=84=B1:
> >> > > >
> >> > > > > Here is my suggestion.
> >> > > > >
> >> > > > > I prefer REST API. I think that it would be better than other
> due
> >> to
> >> > > > > the following reasons:
> >> > > > >
> >> > > > >  * No dependency - most of script languages do not need any
> >> > dependency
> >> > > > > for this approach. Also, C and C++ just needs json library for
> this
> >> > > > > approach. Please look at JSON for Modern C++
> >> > > > > (https://github.com/nlohmann/json). It just requires to includ=
e
> >> one
> >> > > > > header and one source file. As a result, there is no dependenc=
y
> >> > > > > problem.
> >> > > > >
> >> > > > >  * Portability - most of script languages basically support RE=
ST
> >> and
> >> > > > > JSON. They don't need client implementation. They can just use
> REST
> >> > > > > and JSON features in order to access Tajo. If necessary, we ca=
n
> >> make
> >> > > > > easily some helper libraries for other languages.
> >> > > > >
> >> > > > >  * Secure - It is easy to provide the secure channel and
> >> > > > > authentication method too. Basically, many HTTP API provides
> HTTP
> >> > over
> >> > > > > SSL.
> >> > > > >
> >> > > > > Jihoon Kang already started REST API work. If others start to
> >> develop
> >> > > > > clients for other languages like C/C++ client over REST API
> after
> >> his
> >> > > > > work, it would be best for us.
> >> > > > >
> >> > > > > Best regards,
> >> > > > > Hyunsik
> >> > > > >
> >> > > > > On Thu, Mar 12, 2015 at 1:32 AM, Hyunsik Choi <
> hyunsik@apache.org>
> >> > > > wrote:
> >> > > > > > Hi folks,
> >> > > > > >
> >> > > > > > Recently, there are three trials to add new remote client
> APIs.
> >> > > > > >
> >> > > > > > * C/C++ Client over Thrift - https://issues.apache.org/
> >> > > > > jira/browse/TAJO-1264
> >> > > > > > * Add REST Client API -
> >> > > > https://issues.apache.org/jira/browse/TAJO-1331
> >> > > > > > * Tajo Python Native Client - https://issues.apache.org/
> >> > > > > jira/browse/TAJO-1367
> >> > > > > >
> >> > > > > > In some aspect, I'm very happy to discuss such an issue. I
> >> haven't
> >> > > > > > expected that we are discuss and vote for duplicated efforts=
.
> >> > > > > >
> >> > > > > > BTW, it would be great if we do not spend our resource on
> >> > duplicated
> >> > > > > works.
> >> > > > > >
> >> > > > > > In order to rearrange this duplicated works, we need some
> >> > discussion
> >> > > > > > about their pros and cons. I hope that we consent our
> direction
> >> > after
> >> > > > > > this discussion. Otherwise, we can call for a vote for the
> >> > approach.
> >> > > > > >
> >> > > > > > Best regards,
> >> > > > > > Hyunsik
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>

--089e0115f0487a58c605111fea81--