tajo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jihun Kang <ykr...@gmail.com>
Subject Re: [DISCUSSION] Portable remote client APIs
Date Thu, 12 Mar 2015 13:38:45 GMT
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년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hyunsik@apache.org>님이
작성:
> > >
> > > > 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 include one
> > > > header and one source file. As a result, there is no dependency
> > > > problem.
> > > >
> > > >  * Portability - most of script languages basically support REST and
> > > > JSON. They don't need client implementation. They can just use REST
> > > > and JSON features in order to access Tajo. If necessary, we can 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
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message