You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tajo.apache.org by Hyunsik Choi <hy...@apache.org> on 2015/03/12 09:32:47 UTC

[DISCUSSION] Portable remote client APIs

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

Re: [DISCUSSION] Portable remote client APIs

Posted by Jihun Kang <yk...@gmail.com>.
First of all, I am considering to support https scheme in REST api.
However, implementing REST API task was pretty much bigger than expected,
so I decided to separate these two HTTP and HTTPS scheme support. HTTPS
support will be uploaded in near future, when TAJO-1338 task is finished.
Later one looks like implementing authentication on REST API, doesn't it? I
also considering about HTTP basic auth using HTTPS and token based
authentication. I did not decide yet, and selecting authentication method
would be affected by future implementation in security module.

2015-03-20 13:37 GMT+09:00 Dongjoon Hyun <do...@apache.org>:

> Great! I have two questions. (I'm sure you think about these already.)
>
> 1. What about supporting https together?
> 2. What about supporting optional password in Request Message for
> supporting future-proof?
> {
> "userName": "tajo-user",
> "userPassword": "password",
> "databaseName": "default"
> }
>
> Warmly,
> Dongjoon.
>
>
> On Fri, Mar 20, 2015 at 1:25 PM, Jihun Kang <yk...@gmail.com> wrote:
>
> > 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 <hy...@apache.org>:
> >
> > > 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 <ch...@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 <hy...@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 <bl...@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) <je...@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, 정유선 <je...@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" <yk...@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 <ch...@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
> > > >> >> >>> > > > > <hy...@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
> > > >> >> >>> > > > >
> > > >> >> >>> > > >
> > > >> >> >>> > >
> > > >> >> >>> >
> > > >> >> >>>
> > > >> >>
> > > >>
> > >
> >
>

Re: [DISCUSSION] Portable remote client APIs

Posted by Dongjoon Hyun <do...@apache.org>.
Great! I have two questions. (I'm sure you think about these already.)

1. What about supporting https together?
2. What about supporting optional password in Request Message for
supporting future-proof?
{
"userName": "tajo-user",
"userPassword": "password",
"databaseName": "default"
}

Warmly,
Dongjoon.


On Fri, Mar 20, 2015 at 1:25 PM, Jihun Kang <yk...@gmail.com> wrote:

> 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 <hy...@apache.org>:
>
> > 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 <ch...@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 <hy...@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 <bl...@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) <je...@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, 정유선 <je...@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" <yk...@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 <bl...@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 <ch...@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
> > >> >> >>> > > > > <hy...@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
> > >> >> >>> > > > >
> > >> >> >>> > > >
> > >> >> >>> > >
> > >> >> >>> >
> > >> >> >>>
> > >> >>
> > >>
> >
>

Re: [DISCUSSION] Portable remote client APIs

Posted by Jihun Kang <yk...@gmail.com>.
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 <hy...@apache.org>:

> 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 <ch...@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 <hy...@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 <bl...@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) <je...@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, 정유선 <je...@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 <ba...@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" <yk...@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 <bl...@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 <ch...@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
> >> >> >>> > > > > <hy...@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
> >> >> >>> > > > >
> >> >> >>> > > >
> >> >> >>> > >
> >> >> >>> >
> >> >> >>>
> >> >>
> >>
>

Re: [DISCUSSION] Portable remote client APIs

Posted by Hyunsik Choi <hy...@apache.org>.
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 <ch...@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 <hy...@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 <bl...@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) <je...@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, 정유선 <je...@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 <ba...@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" <yk...@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 <bl...@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 <ch...@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 <ji...@apache.org>:
>> >> >>> > >
>> >> >>> > > > +1 for Hyunsik's suggestion.
>> >> >>> > > > I totally agree with you.
>> >> >>> > > >
>> >> >>> > > > Warm regards,
>> >> >>> > > > Jihoon
>> >> >>> > > > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hy...@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
>> >> >>> > > > > <hy...@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
>> >> >>> > > > >
>> >> >>> > > >
>> >> >>> > >
>> >> >>> >
>> >> >>>
>> >>
>>

Re: [DISCUSSION] Portable remote client APIs

Posted by CharSyam <ch...@gmail.com>.
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 <hy...@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 <bl...@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) <je...@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, 정유선 <je...@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 <ba...@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" <yk...@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 <bl...@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 <ch...@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 <ji...@apache.org>:
> >> >>> > >
> >> >>> > > > +1 for Hyunsik's suggestion.
> >> >>> > > > I totally agree with you.
> >> >>> > > >
> >> >>> > > > Warm regards,
> >> >>> > > > Jihoon
> >> >>> > > > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hy...@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
> >> >>> > > > > <hy...@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
> >> >>> > > > >
> >> >>> > > >
> >> >>> > >
> >> >>> >
> >> >>>
> >>
>

Re: [DISCUSSION] Portable remote client APIs

Posted by Hyunsik Choi <hy...@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 <bl...@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) <je...@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, 정유선 <je...@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 <ba...@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" <yk...@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 <bl...@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 <ch...@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 <ji...@apache.org>:
>> >>> > >
>> >>> > > > +1 for Hyunsik's suggestion.
>> >>> > > > I totally agree with you.
>> >>> > > >
>> >>> > > > Warm regards,
>> >>> > > > Jihoon
>> >>> > > > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hy...@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
>> >>> > > > > <hy...@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
>> >>> > > > >
>> >>> > > >
>> >>> > >
>> >>> >
>> >>>
>>

Re: [DISCUSSION] Portable remote client APIs

Posted by Jaehwa Jung <bl...@apache.org>.
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) <je...@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, 정유선 <je...@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 <ba...@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" <yk...@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 <bl...@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 <ch...@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 <ji...@apache.org>:
> >>> > >
> >>> > > > +1 for Hyunsik's suggestion.
> >>> > > > I totally agree with you.
> >>> > > >
> >>> > > > Warm regards,
> >>> > > > Jihoon
> >>> > > > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hy...@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
> >>> > > > > <hy...@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
> >>> > > > >
> >>> > > >
> >>> > >
> >>> >
> >>>
>

RE: [DISCUSSION] Portable remote client APIs

Posted by "정유선 (JUNG YOUSUN)" <je...@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, 정유선 <je...@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 <ba...@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" <yk...@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 <bl...@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 <ch...@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 <ji...@apache.org>:
>>> > >
>>> > > > +1 for Hyunsik's suggestion.
>>> > > > I totally agree with you.
>>> > > >
>>> > > > Warm regards,
>>> > > > Jihoon
>>> > > > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hy...@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 
>>> > > > > <hy...@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
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>

Re: [DISCUSSION] Portable remote client APIs

Posted by Hyunsik Choi <hy...@apache.org>.
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, 정유선 <je...@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 <ba...@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" <yk...@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 <bl...@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 <ch...@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 <ji...@apache.org>:
>>> > >
>>> > > > +1 for Hyunsik's suggestion.
>>> > > > I totally agree with you.
>>> > > >
>>> > > > Warm regards,
>>> > > > Jihoon
>>> > > > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hy...@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
>>> > > > > <hy...@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
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>

RE: [DISCUSSION] Portable remote client APIs

Posted by Ethan <ca...@gmail.com>.
Hey folks,

Any one will be attending ApacheCon at Austin TX next month?

Thanks,

-- 
Ethan


On March 12, 2015 at 11:34:16 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 <ba...@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" <yk...@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 <bl...@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 <ch...@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 <ji...@apache.org>:  
>> > >  
>> > > > +1 for Hyunsik's suggestion.  
>> > > > I totally agree with you.  
>> > > >  
>> > > > Warm regards,  
>> > > > Jihoon  
>> > > > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hy...@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  
>> > > > > <hy...@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  
>> > > > >  
>> > > >  
>> > >  
>> >  
>>  

Re: [DISCUSSION] Portable remote client APIs

Posted by Jihoon Son <ji...@apache.org>.
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 <ji...@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 <ji...@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 최승운 <se...@sk.com> wrote:
>>
>>> I give +1 to maintain both rest and thrift.
>>>
>>> Best regards,
>>> Seungun.
>>> ________________________________________
>>> 보낸 사람: 정유선 <je...@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 <ba...@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" <yk...@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 <bl...@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 <ch...@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 <ji...@apache.org>:
>>> >> > >
>>> >> > > > +1 for Hyunsik's suggestion.
>>> >> > > > I totally agree with you.
>>> >> > > >
>>> >> > > > Warm regards,
>>> >> > > > Jihoon
>>> >> > > > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hy...@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
>>> >> > > > > <hy...@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
>>> >> > > > >
>>> >> > > >
>>> >> > >
>>> >> >
>>> >>
>>>
>>

Re: [DISCUSSION] Portable remote client APIs

Posted by Jihoon Son <ji...@apache.org>.
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 <ji...@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 최승운 <se...@sk.com> wrote:
>
>> I give +1 to maintain both rest and thrift.
>>
>> Best regards,
>> Seungun.
>> ________________________________________
>> 보낸 사람: 정유선 <je...@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 <ba...@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" <yk...@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 <bl...@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 <ch...@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 <ji...@apache.org>:
>> >> > >
>> >> > > > +1 for Hyunsik's suggestion.
>> >> > > > I totally agree with you.
>> >> > > >
>> >> > > > Warm regards,
>> >> > > > Jihoon
>> >> > > > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hy...@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
>> >> > > > > <hy...@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
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>>
>

Re: [DISCUSSION] Portable remote client APIs

Posted by Jihoon Son <ji...@apache.org>.
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 최승운 <se...@sk.com> wrote:

> I give +1 to maintain both rest and thrift.
>
> Best regards,
> Seungun.
> ________________________________________
> 보낸 사람: 정유선 <je...@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 <ba...@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" <yk...@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 <bl...@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 <ch...@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 <ji...@apache.org>:
> >> > >
> >> > > > +1 for Hyunsik's suggestion.
> >> > > > I totally agree with you.
> >> > > >
> >> > > > Warm regards,
> >> > > > Jihoon
> >> > > > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hy...@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
> >> > > > > <hy...@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
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>

RE: [DISCUSSION] Portable remote client APIs

Posted by 최승운 <se...@sk.com>.
I give +1 to maintain both rest and thrift.

Best regards,
Seungun.
________________________________________
보낸 사람: 정유선 <je...@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 <ba...@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" <yk...@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 <bl...@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 <ch...@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 <ji...@apache.org>:
>> > >
>> > > > +1 for Hyunsik's suggestion.
>> > > > I totally agree with you.
>> > > >
>> > > > Warm regards,
>> > > > Jihoon
>> > > > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hy...@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
>> > > > > <hy...@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
>> > > > >
>> > > >
>> > >
>> >
>>

RE: [DISCUSSION] Portable remote client APIs

Posted by 정유선 <je...@sk.com>.
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 <ba...@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" <yk...@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 <bl...@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 <ch...@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 <ji...@apache.org>:
>> > >
>> > > > +1 for Hyunsik's suggestion.
>> > > > I totally agree with you.
>> > > >
>> > > > Warm regards,
>> > > > Jihoon
>> > > > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hy...@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 
>> > > > > <hy...@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
>> > > > >
>> > > >
>> > >
>> >
>>

Re: [DISCUSSION] Portable remote client APIs

Posted by Dongjoon Hyun <do...@apache.org>.
I give +1 to REST API, too.

Best regards,
Dongjoon.


On Fri, Mar 13, 2015 at 8:34 AM, Hyunsik Choi <hy...@apache.org> wrote:

> 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 <ba...@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" <yk...@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 <bl...@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 <ch...@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 <ji...@apache.org>:
> >> > >
> >> > > > +1 for Hyunsik's suggestion.
> >> > > > I totally agree with you.
> >> > > >
> >> > > > Warm regards,
> >> > > > Jihoon
> >> > > > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hy...@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
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>

Re: [DISCUSSION] Portable remote client APIs

Posted by Hyunsik Choi <hy...@apache.org>.
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 <ba...@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" <yk...@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 <bl...@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 <ch...@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 <ji...@apache.org>:
>> > >
>> > > > +1 for Hyunsik's suggestion.
>> > > > I totally agree with you.
>> > > >
>> > > > Warm regards,
>> > > > Jihoon
>> > > > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hy...@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 <hy...@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
>> > > > >
>> > > >
>> > >
>> >
>>

Re: [DISCUSSION] Portable remote client APIs

Posted by Hyoungjun Kim <ba...@gmail.com>.
Hi all,

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

Warm regards,
Hyoungjun
2015. 3. 12. 오후 10:41에 "Jihun Kang" <yk...@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 <bl...@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 <ch...@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 <ji...@apache.org>:
> > >
> > > > +1 for Hyunsik's suggestion.
> > > > I totally agree with you.
> > > >
> > > > Warm regards,
> > > > Jihoon
> > > > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hy...@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 <hy...@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
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSSION] Portable remote client APIs

Posted by Jihun Kang <yk...@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 <bl...@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 <ch...@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 <ji...@apache.org>:
> >
> > > +1 for Hyunsik's suggestion.
> > > I totally agree with you.
> > >
> > > Warm regards,
> > > Jihoon
> > > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hy...@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 <hy...@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
> > > >
> > >
> >
>

Re: [DISCUSSION] Portable remote client APIs

Posted by Jaehwa Jung <bl...@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 <ch...@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 <ji...@apache.org>:
>
> > +1 for Hyunsik's suggestion.
> > I totally agree with you.
> >
> > Warm regards,
> > Jihoon
> > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hy...@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 <hy...@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
> > >
> >
>

Re: [DISCUSSION] Portable remote client APIs

Posted by Jinho Kim <jh...@apache.org>.
+1 RESTful API for code maintenance

-Jinho
Best regards

2015-03-12 17:56 GMT+09:00 CharSyam <ch...@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 <ji...@apache.org>:
>
> > +1 for Hyunsik's suggestion.
> > I totally agree with you.
> >
> > Warm regards,
> > Jihoon
> > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hy...@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 <hy...@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
> > >
> >
>

Re: [DISCUSSION] Portable remote client APIs

Posted by CharSyam <ch...@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 <ji...@apache.org>:

> +1 for Hyunsik's suggestion.
> I totally agree with you.
>
> Warm regards,
> Jihoon
> 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hy...@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 <hy...@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
> >
>

Re: [DISCUSSION] Portable remote client APIs

Posted by Jihoon Son <ji...@apache.org>.
+1 for Hyunsik's suggestion.
I totally agree with you.

Warm regards,
Jihoon
2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <hy...@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 <hy...@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
>

Re: [DISCUSSION] Portable remote client APIs

Posted by Hyunsik Choi <hy...@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 <hy...@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