Return-Path: X-Original-To: apmail-tajo-dev-archive@minotaur.apache.org Delivered-To: apmail-tajo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6579F1768C for ; Fri, 20 Mar 2015 04:26:43 +0000 (UTC) Received: (qmail 58936 invoked by uid 500); 20 Mar 2015 04:26:43 -0000 Delivered-To: apmail-tajo-dev-archive@tajo.apache.org Received: (qmail 58892 invoked by uid 500); 20 Mar 2015 04:26:43 -0000 Mailing-List: contact dev-help@tajo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@tajo.apache.org Delivered-To: mailing list dev@tajo.apache.org Received: (qmail 58881 invoked by uid 99); 20 Mar 2015 04:26:43 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Mar 2015 04:26:43 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ykrips@gmail.com designates 209.85.160.174 as permitted sender) Received: from [209.85.160.174] (HELO mail-yk0-f174.google.com) (209.85.160.174) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Mar 2015 04:26:17 +0000 Received: by ykek76 with SMTP id k76so37328477yke.0 for ; Thu, 19 Mar 2015 21:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=elKVlGyvAExod8Cie6PdzKrejer7MqNkNQd/YWiDal0=; b=pEf3ttG1A+n6G/nTIpH2yssz7GIdiHNlRxX13nL89hZBYh1UGS7K7wb+b+tPKZb8tU qndhl3VJFM86UraevCyNDhJq3/1axTmyx/ASJMqoTXorHu7YTlB5+1S1Z49vvmdS0JGX 5j6iNpZXu9p8d/ACaNeDtr4dLhI9bBArMq6mJfeYOTyKZxww1WBlagmuUpIOILKHceEn VGOEoPg9AvPH91d/fbV1bG9j7o3GPVkz2aQFfkevzDMiEcHRc82nTTDPsU8MyH6HM5Ad 5Ec6HYd+FP0ExJlJMb2Hv5aHdBDmMdR8+kpKNea/MicBVKBcdLht83wxcCkWh6AbqQTK eXnw== MIME-Version: 1.0 X-Received: by 10.236.38.132 with SMTP id a4mr82422978yhb.183.1426825530582; Thu, 19 Mar 2015 21:25:30 -0700 (PDT) Received: by 10.170.86.198 with HTTP; Thu, 19 Mar 2015 21:25:30 -0700 (PDT) In-Reply-To: References: Date: Fri, 20 Mar 2015 13:25:30 +0900 Message-ID: Subject: Re: [DISCUSSION] Portable remote client APIs From: Jihun Kang To: dev@tajo.apache.org Content-Type: multipart/alternative; boundary=089e01537964e82b950511b0b4e8 X-Virus-Checked: Checked by ClamAV on apache.org --089e01537964e82b950511b0b4e8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello All, TAJO REST API design page was created in TAJO wiki page. Please feel free to give any comments on this design. You can find details in following link= . https://cwiki.apache.org/confluence/display/TAJO/TAJO+REST+API 2015-03-17 15:13 GMT+09:00 Hyunsik Choi : > 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 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 : > > > >> 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 > 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 =EC=A0=95=EC=9C=A0=EC=84=A0(JUNG YOUSUN) = : > >> > > >> >> 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 o= n > >> 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 com= e > >> 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 i= n > >> 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, =EC=A0=95=EC=9C=A0=EC=84=A0 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 intera= ct > >> >> > 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 > >> >> wrote: > >> >> >> Hi all, > >> >> >> > >> >> >> I give +1 to REST API. > >> >> >> I think REST is more common. > >> >> >> > >> >> >> Warm regards, > >> >> >> Hyoungjun > >> >> >> 2015. 3. 12. =EC=98=A4=ED=9B=84 10:41=EC=97=90 "Jihun Kang" =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > >> >> >> > >> >> >>> 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 : > >> >> >>> > >> >> >>> > Hi guys > >> >> >>> > > >> >> >>> > +1 for Hyunsik's suggestion. > >> >> >>> > > >> >> >>> > REST API may be more efficient for code maintenance and vario= us > >> >> >>> > clients implementation. > >> >> >>> > > >> >> >>> > Cheers > >> >> >>> > Jaehwa > >> >> >>> > +1 RESTful API for code maintenance > >> >> >>> > > >> >> >>> > -Jinho > >> >> >>> > Best regards > >> >> >>> > > >> >> >>> > 2015-03-12 17:56 GMT+09:00 CharSyam : > >> >> >>> > > >> >> >>> > > +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 >: > >> >> >>> > > > >> >> >>> > > > +1 for Hyunsik's suggestion. > >> >> >>> > > > I totally agree with you. > >> >> >>> > > > > >> >> >>> > > > Warm regards, > >> >> >>> > > > Jihoon > >> >> >>> > > > 2015=EB=85=84 3=EC=9B=94 12=EC=9D=BC (=EB=AA=A9) =EC=98= =A4=ED=9B=84 5:35, Hyunsik Choi >=EB=8B=98=EC=9D=B4 > >> >> =EC=9E=91=EC=84=B1: > >> >> >>> > > > > >> >> >>> > > > > 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 an= d > >> >> >>> > > > > 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 > >> >> >>> > > > > > >> >> >>> > > > 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 resourc= e > 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 fo= r > the > >> >> >>> > approach. > >> >> >>> > > > > > > >> >> >>> > > > > > Best regards, > >> >> >>> > > > > > Hyunsik > >> >> >>> > > > > > >> >> >>> > > > > >> >> >>> > > > >> >> >>> > > >> >> >>> > >> >> > >> > --089e01537964e82b950511b0b4e8--