tajo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dongjoon Hyun <dongj...@apache.org>
Subject Re: [DISCUSSION] Portable remote client APIs
Date Fri, 20 Mar 2015 04:37:58 GMT
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 <ykrips@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 <hyunsik@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 <charsyam@gmail.com> wrote:
> > > Yes :) But I think we need good docs for REST api also for client
> > > developers.
> > >
> > > 2015-03-17 14:32 GMT+09:00 Hyunsik Choi <hyunsik@apache.org>:
> > >
> > >> According to the vote results, let's focus on REST for remote API.
> > >>
> > >> Best regards,
> > >> Hyunsik
> > >>
> > >> On Thu, Mar 12, 2015 at 11:36 PM, Jaehwa Jung <blrunner@apache.org>
> > wrote:
> > >> > This discussion started to avoid duplicated efforts.
> > >> > IMPOV, if we choice both of REST and Thrift, it may be complex to
> > >> maintain
> > >> > Tajo codes.
> > >> >
> > >> > 2015-03-13 15:28 GMT+09:00 정유선(JUNG YOUSUN) <jerryjung@sk.com>:
> > >> >
> > >> >> Yep! I just think both can support multiple language client.
> > >> >> As you mentioned, it is not critical issues about performance
in
> > Thrift.
> > >> >> Anyway, I think it's a good discussion about the remote interface
> on
> > >> Tajo.
> > >> >> :)
> > >> >>
> > >> >> Sincerely,
> > >> >> Yousun Jeong
> > >> >>
> > >> >> -----Original Message-----
> > >> >> From: Hyunsik Choi [mailto:hyunsik@apache.org]
> > >> >> Sent: Friday, March 13, 2015 2:59 PM
> > >> >> To: dev@tajo.apache.org
> > >> >> Subject: Re: [DISCUSSION] Portable remote client APIs
> > >> >>
> > >> >> Hi Jerry,
> > >> >>
> > >> >> How much faster and lightweight than REST? Luckily, Thrift may
be
> > faster
> > >> >> 1~2 msec than REST per call.
> > >> >>
> > >> >> But, note that Tajo is an analytical system. The target response
> > times
> > >> of
> > >> >> Tajo are usually from few seconds to hours. So, the speed which
> come
> > >> from
> > >> >> wired protocol is much trivial to the purpose of our client APIs.
> > >> >>
> > >> >> The link you introduce is about Hbase. As you know, Hbase is
> > OLTP-like
> > >> >> system. It processes thousands of transactions per seconds. So,
the
> > >> speed
> > >> >> and lightweight are important to them. But, Tajo is not.
> > >> >>
> > >> >> As I mentioned, REST API is very portable and has no dependencies
> in
> > >> many
> > >> >> languages. I think that these are the most important factors of
our
> > >> client
> > >> >> APIs.
> > >> >>
> > >> >> Best regards,
> > >> >> Hyunsik
> > >> >>
> > >> >> On Thu, Mar 12, 2015 at 9:33 PM, 정유선 <jerryjung@sk.com>
wrote:
> > >> >> > I suggest another option.
> > >> >> > What do you think about two options for remote interface?
> > >> >> > Thrift is the faster and more lightweight than REST.
> > >> >> > Please refer this article.
> > >> >> > -
> > >> >> >
> > >>
> http://blog.cloudera.com/blog/2013/03/how-to-use-the-apache-hbase-rest
> > >> >> > -interface-part-1/ It describes various ways to access and
> interact
> > >> >> > with HBase.
> > >> >> > Both of them, giving developers a wide choice of languages
and
> > >> programs
> > >> >> to use.
> > >> >> >
> > >> >> > Best regards,
> > >> >> > Yousun Jeong.
> > >> >> >
> > >> >> > -----Original Message-----
> > >> >> > From: Hyunsik Choi [mailto:hyunsik@apache.org]
> > >> >> > Sent: Friday, March 13, 2015 8:34 AM
> > >> >> > To: dev@tajo.apache.org
> > >> >> > Subject: Re: [DISCUSSION] Portable remote client APIs
> > >> >> >
> > >> >> > We seem to get a consent to use REST API. I'll wait for one
more
> > day,
> > >> >> and then we can decide this issue.
> > >> >> >
> > >> >> > Best regards,
> > >> >> > Hyunsik
> > >> >> >
> > >> >> > On Thu, Mar 12, 2015 at 7:56 AM, Hyoungjun Kim <
> babokim@gmail.com>
> > >> >> wrote:
> > >> >> >> Hi all,
> > >> >> >>
> > >> >> >> I give +1 to REST API.
> > >> >> >> I think REST is more common.
> > >> >> >>
> > >> >> >> Warm regards,
> > >> >> >> Hyoungjun
> > >> >> >> 2015. 3. 12. 오후 10:41에 "Jihun Kang" <ykrips@gmail.com>님이
작성:
> > >> >> >>
> > >> >> >>> Hello All,
> > >> >> >>>
> > >> >> >>> I would give +1 to REST API Implementation. Even
Protobuf and
> > Thrift
> > >> >> >>> give flexibility and extensibility to programmers,
but entry
> > >> >> >>> barriers for these frameworks are extremely high.
Also, if we
> > want
> > >> >> >>> to make another client implementation for other programming
> > >> >> >>> languages, we need to figure out that these framework
have code
> > >> >> generator feature for that programming language.
> > >> >> >>>
> > >> >> >>> 2015-03-12 20:18 GMT+09:00 Jaehwa Jung <blrunner@apache.org>:
> > >> >> >>>
> > >> >> >>> > Hi guys
> > >> >> >>> >
> > >> >> >>> > +1 for Hyunsik's suggestion.
> > >> >> >>> >
> > >> >> >>> > REST API may be more efficient for code maintenance
and
> various
> > >> >> >>> > clients implementation.
> > >> >> >>> >
> > >> >> >>> > Cheers
> > >> >> >>> > Jaehwa
> > >> >> >>> >  +1 RESTful API for code maintenance
> > >> >> >>> >
> > >> >> >>> > -Jinho
> > >> >> >>> > Best regards
> > >> >> >>> >
> > >> >> >>> > 2015-03-12 17:56 GMT+09:00 CharSyam <charsyam@gmail.com>:
> > >> >> >>> >
> > >> >> >>> > > +1
> > >> >> >>> > >
> > >> >> >>> > > I also agree with hyunsik's suggesttion.
> > >> >> >>> > > I think it is better to make language binding
to use Rest
> > API.
> > >> >> >>> > > It will be more efficient and less effort
:)
> > >> >> >>> > >
> > >> >> >>> > > 2015-03-12 17:38 GMT+09:00 Jihoon Son <
> jihoonson@apache.org
> > >:
> > >> >> >>> > >
> > >> >> >>> > > > +1 for Hyunsik's suggestion.
> > >> >> >>> > > > I totally agree with you.
> > >> >> >>> > > >
> > >> >> >>> > > > Warm regards,
> > >> >> >>> > > > Jihoon
> > >> >> >>> > > > 2015년 3월 12일 (목) 오후 5:35,
Hyunsik Choi <
> hyunsik@apache.org
> > >님이
> > >> >> 작성:
> > >> >> >>> > > >
> > >> >> >>> > > > > Here is my suggestion.
> > >> >> >>> > > > >
> > >> >> >>> > > > > I prefer REST API. I think that
it would be better than
> > >> >> >>> > > > > other due
> > >> >> >>> to
> > >> >> >>> > > > > the following reasons:
> > >> >> >>> > > > >
> > >> >> >>> > > > >  * No dependency - most of script
languages do not need
> > any
> > >> >> >>> > dependency
> > >> >> >>> > > > > for this approach. Also, C and
C++ just needs json
> > library
> > >> >> >>> > > > > for this approach. Please look
at JSON for Modern C++
> > >> >> >>> > > > > (https://github.com/nlohmann/json).
It just requires
> to
> > >> >> >>> > > > > include
> > >> >> >>> one
> > >> >> >>> > > > > header and one source file. As
a result, there is no
> > >> >> >>> > > > > dependency problem.
> > >> >> >>> > > > >
> > >> >> >>> > > > >  * Portability - most of script
languages basically
> > support
> > >> >> >>> > > > > REST
> > >> >> >>> and
> > >> >> >>> > > > > JSON. They don't need client
implementation. They can
> > just
> > >> >> >>> > > > > use REST and JSON features in
order to access Tajo. If
> > >> >> >>> > > > > necessary, we can
> > >> >> >>> make
> > >> >> >>> > > > > easily some helper libraries
for other languages.
> > >> >> >>> > > > >
> > >> >> >>> > > > >  * Secure - It is easy to provide
the secure channel
> and
> > >> >> >>> > > > > authentication method too. Basically,
many HTTP API
> > provides
> > >> >> >>> > > > > HTTP
> > >> >> >>> > over
> > >> >> >>> > > > > SSL.
> > >> >> >>> > > > >
> > >> >> >>> > > > > Jihoon Kang already started REST
API work. If others
> > start
> > >> >> >>> > > > > to
> > >> >> >>> develop
> > >> >> >>> > > > > clients for other languages like
C/C++ client over REST
> > API
> > >> >> >>> > > > > after
> > >> >> >>> his
> > >> >> >>> > > > > work, it would be best for us.
> > >> >> >>> > > > >
> > >> >> >>> > > > > Best regards,
> > >> >> >>> > > > > Hyunsik
> > >> >> >>> > > > >
> > >> >> >>> > > > > On Thu, Mar 12, 2015 at 1:32
AM, Hyunsik Choi
> > >> >> >>> > > > > <hyunsik@apache.org>
> > >> >> >>> > > > wrote:
> > >> >> >>> > > > > > Hi folks,
> > >> >> >>> > > > > >
> > >> >> >>> > > > > > Recently, there are three
trials to add new remote
> > client
> > >> >> APIs.
> > >> >> >>> > > > > >
> > >> >> >>> > > > > > * C/C++ Client over Thrift
-
> > https://issues.apache.org/
> > >> >> >>> > > > > jira/browse/TAJO-1264
> > >> >> >>> > > > > > * Add REST Client API -
> > >> >> >>> > > > https://issues.apache.org/jira/browse/TAJO-1331
> > >> >> >>> > > > > > * Tajo Python Native Client
-
> > https://issues.apache.org/
> > >> >> >>> > > > > jira/browse/TAJO-1367
> > >> >> >>> > > > > >
> > >> >> >>> > > > > > In some aspect, I'm very
happy to discuss such an
> > issue. I
> > >> >> >>> haven't
> > >> >> >>> > > > > > expected that we are discuss
and vote for duplicated
> > >> efforts.
> > >> >> >>> > > > > >
> > >> >> >>> > > > > > BTW, it would be great if
we do not spend our
> resource
> > on
> > >> >> >>> > duplicated
> > >> >> >>> > > > > works.
> > >> >> >>> > > > > >
> > >> >> >>> > > > > > In order to rearrange this
duplicated works, we need
> > some
> > >> >> >>> > discussion
> > >> >> >>> > > > > > about their pros and cons.
I hope that we consent our
> > >> >> >>> > > > > > direction
> > >> >> >>> > after
> > >> >> >>> > > > > > this discussion. Otherwise,
we can call for a vote
> for
> > the
> > >> >> >>> > approach.
> > >> >> >>> > > > > >
> > >> >> >>> > > > > > Best regards,
> > >> >> >>> > > > > > Hyunsik
> > >> >> >>> > > > >
> > >> >> >>> > > >
> > >> >> >>> > >
> > >> >> >>> >
> > >> >> >>>
> > >> >>
> > >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message