I give +1 to REST API, too. Best regards, Dongjoon.
On Fri, Mar 13, 2015 at 8:34 AM, Hyunsik Choi <[email protected]> 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 <[email protected]> wrote: > > Hi all, > > > > I give +1 to REST API. > > I think REST is more common. > > > > Warm regards, > > Hyoungjun > > 2015. 3. 12. 오후 10:41에 "Jihun Kang" <[email protected]>님이 작성: > > > >> Hello All, > >> > >> I would give +1 to REST API Implementation. Even Protobuf and Thrift > give > >> flexibility and extensibility to programmers, but entry barriers for > these > >> frameworks are extremely high. Also, if we want to make another client > >> implementation for other programming languages, we need to figure out > that > >> these framework have code generator feature for that programming > language. > >> > >> 2015-03-12 20:18 GMT+09:00 Jaehwa Jung <[email protected]>: > >> > >> > Hi guys > >> > > >> > +1 for Hyunsik's suggestion. > >> > > >> > REST API may be more efficient for code maintenance and various > clients > >> > implementation. > >> > > >> > Cheers > >> > Jaehwa > >> > +1 RESTful API for code maintenance > >> > > >> > -Jinho > >> > Best regards > >> > > >> > 2015-03-12 17:56 GMT+09:00 CharSyam <[email protected]>: > >> > > >> > > +1 > >> > > > >> > > I also agree with hyunsik's suggesttion. > >> > > I think it is better to make language binding to use Rest API. > >> > > It will be more efficient and less effort :) > >> > > > >> > > 2015-03-12 17:38 GMT+09:00 Jihoon Son <[email protected]>: > >> > > > >> > > > +1 for Hyunsik's suggestion. > >> > > > I totally agree with you. > >> > > > > >> > > > Warm regards, > >> > > > Jihoon > >> > > > 2015년 3월 12일 (목) 오후 5:35, Hyunsik Choi <[email protected]>님이 작성: > >> > > > > >> > > > > Here is my suggestion. > >> > > > > > >> > > > > I prefer REST API. I think that it would be better than other > due > >> to > >> > > > > the following reasons: > >> > > > > > >> > > > > * No dependency - most of script languages do not need any > >> > dependency > >> > > > > for this approach. Also, C and C++ just needs json library for > this > >> > > > > approach. Please look at JSON for Modern C++ > >> > > > > (https://github.com/nlohmann/json). It just requires to include > >> one > >> > > > > header and one source file. As a result, there is no dependency > >> > > > > problem. > >> > > > > > >> > > > > * Portability - most of script languages basically support REST > >> and > >> > > > > JSON. They don't need client implementation. They can just use > REST > >> > > > > and JSON features in order to access Tajo. If necessary, we can > >> make > >> > > > > easily some helper libraries for other languages. > >> > > > > > >> > > > > * Secure - It is easy to provide the secure channel and > >> > > > > authentication method too. Basically, many HTTP API provides > HTTP > >> > over > >> > > > > SSL. > >> > > > > > >> > > > > Jihoon Kang already started REST API work. If others start to > >> develop > >> > > > > clients for other languages like C/C++ client over REST API > after > >> his > >> > > > > work, it would be best for us. > >> > > > > > >> > > > > Best regards, > >> > > > > Hyunsik > >> > > > > > >> > > > > On Thu, Mar 12, 2015 at 1:32 AM, Hyunsik Choi < > [email protected]> > >> > > > wrote: > >> > > > > > Hi folks, > >> > > > > > > >> > > > > > Recently, there are three trials to add new remote client > APIs. > >> > > > > > > >> > > > > > * C/C++ Client over Thrift - https://issues.apache.org/ > >> > > > > jira/browse/TAJO-1264 > >> > > > > > * Add REST Client API - > >> > > > https://issues.apache.org/jira/browse/TAJO-1331 > >> > > > > > * Tajo Python Native Client - https://issues.apache.org/ > >> > > > > jira/browse/TAJO-1367 > >> > > > > > > >> > > > > > In some aspect, I'm very happy to discuss such an issue. I > >> haven't > >> > > > > > expected that we are discuss and vote for duplicated efforts. > >> > > > > > > >> > > > > > BTW, it would be great if we do not spend our resource on > >> > duplicated > >> > > > > works. > >> > > > > > > >> > > > > > In order to rearrange this duplicated works, we need some > >> > discussion > >> > > > > > about their pros and cons. I hope that we consent our > direction > >> > after > >> > > > > > this discussion. Otherwise, we can call for a vote for the > >> > approach. > >> > > > > > > >> > > > > > Best regards, > >> > > > > > Hyunsik > >> > > > > > >> > > > > >> > > > >> > > >> >
