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) <[email protected]>: > 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:[email protected]] > Sent: Friday, March 13, 2015 2:59 PM > To: [email protected] > 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, 정유선 <[email protected]> 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:[email protected]] > > Sent: Friday, March 13, 2015 8:34 AM > > To: [email protected] > > 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 <[email protected]> > 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" <[email protected]>님이 작성: > >> > >>> 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 <[email protected]>: > >>> > >>> > 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 <[email protected]>: > >>> > > >>> > > +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 <[email protected]>: > >>> > > > >>> > > > +1 for Hyunsik's suggestion. > >>> > > > I totally agree with you. > >>> > > > > >>> > > > Warm regards, > >>> > > > Jihoon > >>> > > > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <[email protected]>님이 > 작성: > >>> > > > > >>> > > > > 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 > >>> > > > > <[email protected]> > >>> > > > 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 > >>> > > > > > >>> > > > > >>> > > > >>> > > >>> >
