tajo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hyoungjun Kim <babo...@gmail.com>
Subject Re: [DISCUSSION] Portable remote client APIs
Date Thu, 12 Mar 2015 14:56:05 GMT
Hi all,

I give +1 to REST API.
I think REST is more common.

Warm regards,
Hyoungjun
2015. 3. 12. 오후 10:41에 "Jihun Kang" <ykrips@gmail.com>님이 작성:

> 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