tajo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hyunsik Choi <hyun...@apache.org>
Subject Re: [DISCUSSION] Portable remote client APIs
Date Tue, 17 Mar 2015 06:13:06 GMT
Hi CharSyam,

Thank you for suggestion. Yes, the REST api will be updated. Please
see the attach file at
https://issues.apache.org/jira/browse/TAJO-1331. Jihun already wrote
the first draft of REST API.

Best regards,
Hyunsik

On Mon, Mar 16, 2015 at 10:59 PM, CharSyam <charsyam@gmail.com> wrote:
> Yes :) But I think we need good docs for REST api also for client
> developers.
>
> 2015-03-17 14:32 GMT+09:00 Hyunsik Choi <hyunsik@apache.org>:
>
>> According to the vote results, let's focus on REST for remote API.
>>
>> Best regards,
>> Hyunsik
>>
>> On Thu, Mar 12, 2015 at 11:36 PM, Jaehwa Jung <blrunner@apache.org> wrote:
>> > This discussion started to avoid duplicated efforts.
>> > IMPOV, if we choice both of REST and Thrift, it may be complex to
>> maintain
>> > Tajo codes.
>> >
>> > 2015-03-13 15:28 GMT+09:00 정유선(JUNG YOUSUN) <jerryjung@sk.com>:
>> >
>> >> Yep! I just think both can support multiple language client.
>> >> As you mentioned, it is not critical issues about performance in Thrift.
>> >> Anyway, I think it's a good discussion about the remote interface on
>> Tajo.
>> >> :)
>> >>
>> >> Sincerely,
>> >> Yousun Jeong
>> >>
>> >> -----Original Message-----
>> >> From: Hyunsik Choi [mailto:hyunsik@apache.org]
>> >> Sent: Friday, March 13, 2015 2:59 PM
>> >> To: dev@tajo.apache.org
>> >> Subject: Re: [DISCUSSION] Portable remote client APIs
>> >>
>> >> Hi Jerry,
>> >>
>> >> How much faster and lightweight than REST? Luckily, Thrift may be faster
>> >> 1~2 msec than REST per call.
>> >>
>> >> But, note that Tajo is an analytical system. The target response times
>> of
>> >> Tajo are usually from few seconds to hours. So, the speed which come
>> from
>> >> wired protocol is much trivial to the purpose of our client APIs.
>> >>
>> >> The link you introduce is about Hbase. As you know, Hbase is OLTP-like
>> >> system. It processes thousands of transactions per seconds. So, the
>> speed
>> >> and lightweight are important to them. But, Tajo is not.
>> >>
>> >> As I mentioned, REST API is very portable and has no dependencies in
>> many
>> >> languages. I think that these are the most important factors of our
>> client
>> >> APIs.
>> >>
>> >> Best regards,
>> >> Hyunsik
>> >>
>> >> On Thu, Mar 12, 2015 at 9:33 PM, 정유선 <jerryjung@sk.com> wrote:
>> >> > I suggest another option.
>> >> > What do you think about two options for remote interface?
>> >> > Thrift is the faster and more lightweight than REST.
>> >> > Please refer this article.
>> >> > -
>> >> >
>> http://blog.cloudera.com/blog/2013/03/how-to-use-the-apache-hbase-rest
>> >> > -interface-part-1/ It describes various ways to access and interact
>> >> > with HBase.
>> >> > Both of them, giving developers a wide choice of languages and
>> programs
>> >> to use.
>> >> >
>> >> > Best regards,
>> >> > Yousun Jeong.
>> >> >
>> >> > -----Original Message-----
>> >> > From: Hyunsik Choi [mailto:hyunsik@apache.org]
>> >> > Sent: Friday, March 13, 2015 8:34 AM
>> >> > To: dev@tajo.apache.org
>> >> > Subject: Re: [DISCUSSION] Portable remote client APIs
>> >> >
>> >> > 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. 오후 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
View raw message