tajo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jihoon Son <jihoon...@apache.org>
Subject Re: [DISCUSSION] Portable remote client APIs
Date Fri, 13 Mar 2015 05:38:15 GMT
Sorry, it was my misunderstanding.
We still have no plan to support Thrift interface.

Sincerely,
Jihoon

On Fri, Mar 13, 2015 at 2:32 PM Jihoon Son <jihoonson@apache.org> wrote:

> I missed one thing.
> It is not true that we will not provide the Thrift interface.
> We will provide the Thrift interface using REST.
>
> Sincerely,
> Jihoon
>
>
> On Fri, Mar 13, 2015 at 2:28 PM Jihoon Son <jihoonson@apache.org> wrote:
>
>> Jerryjung, thanks for your suggestion.
>> As you said, Thrift will be faster and more lightweight than REST.
>> However, most native protocols are faster than REST. So, this cannot be a
>> reason for using Thrift.
>>
>> Alternatively, maintaining various types of protocols can be an option.
>> However, this will cause much greater maintenance cost.
>>
>> Even though the link which you gave above is not for comparing the
>> performance Thrift and REST protocols, there is a paragraph as follows.
>>
>> There are two main approaches for doing that: One is the Thrift interface
>>> <http://wiki.apache.org/hadoop/Hbase/ThriftApi>, which is the faster
>>> and more lightweight of the two options. The other way to access HBase is
>>> using the REST interface <http://wiki.apache.org/hadoop/Hbase/Stargate>,
>>> which uses HTTP verbs to perform an action, giving developers a wide choice
>>> of languages and programs to use.
>>>
>>
>> As indicated here, REST can be a good candidate to support various
>> languages and programs.
>> In addition, I think that the performance of Client APIs does not matter
>> because it's contribution to the entire query performance is very little.
>>
>> Welcome any arguments.
>>
>> Sincerely,
>> Jihoon
>>
>> On Fri, Mar 13, 2015 at 2:01 PM 최승운 <seungun.choe@sk.com> wrote:
>>
>>> I give +1 to maintain both rest and thrift.
>>>
>>> Best regards,
>>> Seungun.
>>> ________________________________________
>>> 보낸 사람: 정유선 <jerryjung@sk.com>
>>> 보낸 날짜: 2015년 3월 13일 금요일 오후 1:33
>>> 받는 사람: dev@tajo.apache.org
>>> 제목: RE: [DISCUSSION] Portable remote client APIs
>>>
>>> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message