[jira] [Created] (THRIFT-4223) Add support to the isServing() method for the C++ library
Erick Arroyo created THRIFT-4223: Summary: Add support to the isServing() method for the C++ library Key: THRIFT-4223 URL: https://issues.apache.org/jira/browse/THRIFT-4223 Project: Thrift Issue Type: Improvement Components: C++ - Library Affects Versions: 0.10.0 Environment: Linux Reporter: Erick Arroyo Fix For: 0.11.0 It is important to add support to the isServing() method for the C++ library and in the other supported languages. This method is already exposed on the Java library. This method is very useful to determine when exactly the server is in listening state and also can be used to fix for example race conditions between the server and the client. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (THRIFT-4222) Support Unix Domain Sockets in Golang TServerSocket
Zach Wasserman created THRIFT-4222: -- Summary: Support Unix Domain Sockets in Golang TServerSocket Key: THRIFT-4222 URL: https://issues.apache.org/jira/browse/THRIFT-4222 Project: Thrift Issue Type: Improvement Components: Go - Library Reporter: Zach Wasserman The existing API only supports opening TCP sockets. A minor change (in accordance with the existing API for TSocket) allows for use of unix domain sockets. This will obviate the need for a library like this (https://github.com/Wang/thrift_unix_domain/blob/master/server_unix_domain.go) which is mostly a copy of the existing code with minor changes to support the domain socket. Patch available: https://github.com/apache/thrift/pull/1284 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-4222) Support Unix Domain Sockets in Golang TServerSocket
[ https://issues.apache.org/jira/browse/THRIFT-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16037211#comment-16037211 ] ASF GitHub Bot commented on THRIFT-4222: Github user zwass commented on the issue: https://github.com/apache/thrift/pull/1284 JIRA ticket filed: https://issues.apache.org/jira/browse/THRIFT-4222 > Support Unix Domain Sockets in Golang TServerSocket > --- > > Key: THRIFT-4222 > URL: https://issues.apache.org/jira/browse/THRIFT-4222 > Project: Thrift > Issue Type: Improvement > Components: Go - Library >Reporter: Zach Wasserman > > The existing API only supports opening TCP sockets. A minor change (in > accordance with the existing API for TSocket) allows for use of unix domain > sockets. > This will obviate the need for a library like this > (https://github.com/Wang/thrift_unix_domain/blob/master/server_unix_domain.go) > which is mostly a copy of the existing code with minor changes to support > the domain socket. > Patch available: https://github.com/apache/thrift/pull/1284 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift issue #1284: THRIFT-4222: Add Golang NewTServerSocketFromAddrTimeout
Github user zwass commented on the issue: https://github.com/apache/thrift/pull/1284 JIRA ticket filed: https://issues.apache.org/jira/browse/THRIFT-4222 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-3773) Swift Library
[ https://issues.apache.org/jira/browse/THRIFT-3773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16037169#comment-16037169 ] ASF GitHub Bot commented on THRIFT-3773: Github user apocolipse commented on the issue: https://github.com/apache/thrift/pull/1084 @gotev feel free to contribute anything that was mentioned there. Its otherwise code complete (and likely better supported than the already merged Swift2 and Cocoa/Obj-C generators), I will contribute more to tests as I can but its not high priority for me right now. > Swift Library > - > > Key: THRIFT-3773 > URL: https://issues.apache.org/jira/browse/THRIFT-3773 > Project: Thrift > Issue Type: New Feature > Components: Swift - Library >Reporter: Thomas Bartelmess >Assignee: Chris Simpson > > We already have the option to generate Swift code in the Cocoa compiler, > however large parts of the (Objective-C) Cocoa Library still depend on Cocoa > and Objective-C. > It would be good to have a native Swift library that doesn't depend on the > Cocoa libraries. > Design goals: > - Fully compatible with the code that is currently generated by the Cocoa > compiler (both Objective-C and Swift). > - Ability to run on Linux > - Pure Swift, no Objective-C code. > - No dependencies on closed source apple libraries > - Keep the same interface, so that the library is compatible with the code > the current cocoa compiler generates > - Better server support that the current Objective-C library. > - Follow the new Swift packaging format to be compatible with the Swift > Package manager -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library
Github user apocolipse commented on the issue: https://github.com/apache/thrift/pull/1084 @gotev feel free to contribute anything that was mentioned there. Its otherwise code complete (and likely better supported than the already merged Swift2 and Cocoa/Obj-C generators), I will contribute more to tests as I can but its not high priority for me right now. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-4215) Golang TTransportFactory Pattern Squelches Errors
[
https://issues.apache.org/jira/browse/THRIFT-4215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16036953#comment-16036953
]
ASF GitHub Bot commented on THRIFT-4215:
Github user dcelasun closed the pull request at:
https://github.com/apache/thrift/pull/1286
> Golang TTransportFactory Pattern Squelches Errors
> -
>
> Key: THRIFT-4215
> URL: https://issues.apache.org/jira/browse/THRIFT-4215
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library
>Affects Versions: 0.10.0
>Reporter: James Mouradian
>Assignee: Can Celasun
> Fix For: 0.11.0
>
>
> The current (as of 72ca60d) pattern for [TTransport
> factories|https://github.com/apache/thrift/blob/master/lib/go/thrift/transport_factory.go#L26]
> in Golang is
> {code}
> type TTransportFactory interface {
> GetTransport(trans TTransport) TTransport
> }
> {code}
> This causes issues, because some {{TTransportFactory}} implementations can
> return and error. Consider the
> [THttpClientTransportFactory|https://github.com/apache/thrift/blob/master/lib/go/thrift/http_client.go#L52],
> which as of of 72ca60d, includes the following snippet:
>
> {code}
> s, _ := NewTHttpClientWithOptions(p.url, p.options)
> return s
> {code}
> The call to {{NewTHttpClientWithOptions(...)}} call can throw errors. The
> resultant behavior is that {{nil}} is returned in place of a valid
> {{TTransport}}, with a {{nil}} error.
> The {{TTransportFactory}} interface (and associated use patterns) should be
> extended to include errors.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift pull request #1286: THRIFT-4215 Make transport factories return error...
Github user dcelasun closed the pull request at: https://github.com/apache/thrift/pull/1286 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (THRIFT-4216) Golang Http Clients Do Not Respect User Options
[
https://issues.apache.org/jira/browse/THRIFT-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Can Celasun resolved THRIFT-4216.
-
Resolution: Fixed
Fix Version/s: 0.11.0
> Golang Http Clients Do Not Respect User Options
> ---
>
> Key: THRIFT-4216
> URL: https://issues.apache.org/jira/browse/THRIFT-4216
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library
>Reporter: James Mouradian
>Assignee: Can Celasun
> Fix For: 0.11.0
>
>
> As of 72ca60d, the instantiation of an http client with user-supplied options
> ([NewTHttpClientWithOptions|https://github.com/apache/thrift/blob/master/lib/go/thrift/http_client.go#L93])
> disregards options.
> The target endpoint is tested with the following snippet:
> {code}
> response, err := http.Get(urlstr)
> {code}
> However, a user-supplied {{THttpClientOptions}} contains a client that should
> be used to test the endpoint instead, i.e.,
> {code}
> response, err := options.Client.Get(urlstr)
> {code}
> The user-supplied client may have settings that are required to communicate
> with the target endpoint.
> Though this fix seems simple, I have not supplied a patch, as this fix should
> likely be bundled with a greater overarching patch to THRIFT-4215. That is
> because the single line change above may not include all the fixes necessary
> to propagate client options correctly through the construction of a
> {{THttpTransport}}, and further errors are squelched.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-4216) Golang Http Clients Do Not Respect User Options
[
https://issues.apache.org/jira/browse/THRIFT-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16036944#comment-16036944
]
Can Celasun commented on THRIFT-4216:
-
[~jensg] not exactly a duplicate but yes, it's fixed with that commit. I'm
closing this one.
> Golang Http Clients Do Not Respect User Options
> ---
>
> Key: THRIFT-4216
> URL: https://issues.apache.org/jira/browse/THRIFT-4216
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library
>Reporter: James Mouradian
>Assignee: Can Celasun
> Fix For: 0.11.0
>
>
> As of 72ca60d, the instantiation of an http client with user-supplied options
> ([NewTHttpClientWithOptions|https://github.com/apache/thrift/blob/master/lib/go/thrift/http_client.go#L93])
> disregards options.
> The target endpoint is tested with the following snippet:
> {code}
> response, err := http.Get(urlstr)
> {code}
> However, a user-supplied {{THttpClientOptions}} contains a client that should
> be used to test the endpoint instead, i.e.,
> {code}
> response, err := options.Client.Get(urlstr)
> {code}
> The user-supplied client may have settings that are required to communicate
> with the target endpoint.
> Though this fix seems simple, I have not supplied a patch, as this fix should
> likely be bundled with a greater overarching patch to THRIFT-4215. That is
> because the single line change above may not include all the fixes necessary
> to propagate client options correctly through the construction of a
> {{THttpTransport}}, and further errors are squelched.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (THRIFT-4216) Golang Http Clients Do Not Respect User Options
[
https://issues.apache.org/jira/browse/THRIFT-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Can Celasun closed THRIFT-4216.
---
Resolution: Fixed
> Golang Http Clients Do Not Respect User Options
> ---
>
> Key: THRIFT-4216
> URL: https://issues.apache.org/jira/browse/THRIFT-4216
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library
>Reporter: James Mouradian
>Assignee: Can Celasun
>
> As of 72ca60d, the instantiation of an http client with user-supplied options
> ([NewTHttpClientWithOptions|https://github.com/apache/thrift/blob/master/lib/go/thrift/http_client.go#L93])
> disregards options.
> The target endpoint is tested with the following snippet:
> {code}
> response, err := http.Get(urlstr)
> {code}
> However, a user-supplied {{THttpClientOptions}} contains a client that should
> be used to test the endpoint instead, i.e.,
> {code}
> response, err := options.Client.Get(urlstr)
> {code}
> The user-supplied client may have settings that are required to communicate
> with the target endpoint.
> Though this fix seems simple, I have not supplied a patch, as this fix should
> likely be bundled with a greater overarching patch to THRIFT-4215. That is
> because the single line change above may not include all the fixes necessary
> to propagate client options correctly through the construction of a
> {{THttpTransport}}, and further errors are squelched.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (THRIFT-4216) Golang Http Clients Do Not Respect User Options
[
https://issues.apache.org/jira/browse/THRIFT-4216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Can Celasun reopened THRIFT-4216:
-
> Golang Http Clients Do Not Respect User Options
> ---
>
> Key: THRIFT-4216
> URL: https://issues.apache.org/jira/browse/THRIFT-4216
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library
>Reporter: James Mouradian
>Assignee: Can Celasun
> Fix For: 0.11.0
>
>
> As of 72ca60d, the instantiation of an http client with user-supplied options
> ([NewTHttpClientWithOptions|https://github.com/apache/thrift/blob/master/lib/go/thrift/http_client.go#L93])
> disregards options.
> The target endpoint is tested with the following snippet:
> {code}
> response, err := http.Get(urlstr)
> {code}
> However, a user-supplied {{THttpClientOptions}} contains a client that should
> be used to test the endpoint instead, i.e.,
> {code}
> response, err := options.Client.Get(urlstr)
> {code}
> The user-supplied client may have settings that are required to communicate
> with the target endpoint.
> Though this fix seems simple, I have not supplied a patch, as this fix should
> likely be bundled with a greater overarching patch to THRIFT-4215. That is
> because the single line change above may not include all the fixes necessary
> to propagate client options correctly through the construction of a
> {{THttpTransport}}, and further errors are squelched.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.
[
https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16036873#comment-16036873
]
Mike Gresens commented on THRIFT-2221:
--
In my option std::unique_ptr is always available if C++11.
See http://en.cppreference.com/w/cpp/memory/unique_ptr
See
http://www.boost.org/doc/libs/1_64_0/libs/config/doc/html/boost_config/boost_macro_reference.html
@ BOOST_NO_CXX11_SMART_PTR
So the block
{code}
+ #if __cplusplus >= 201103L && (defined(__clang__) || __cpp_alias_templates
>= 200704)
+using scoped_ptr = std::unique_ptr;
+ #else
+using ::boost::scoped_ptr;
{code}
can be replaced by
{code}
template using scoped_ptr = std::unique_ptr;
{code}
And remove the block
{code}
+ #if __cplusplus < 201103L
+#include
+ #endif
{code}
Mike...
> Generate c++ code with std::shared_ptr instead of boost::shared_ptr.
>
>
> Key: THRIFT-2221
> URL: https://issues.apache.org/jira/browse/THRIFT-2221
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Compiler
>Affects Versions: 0.9.1
> Environment: C++11 compilers with std::shared_ptr support
>Reporter: Chris Stylianou
>Assignee: James E. King, III
> Labels: c++11, compiler, thrift
>
> Most modern compilers now have full support for std::shared_ptr when enable
> with c++11 flags. It would be nice to have the option to generate code that
> uses this instead of boost::shared_ptr. This would enable us to remove
> another boost dependency, on the road to a dependency-free thrift library :)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (THRIFT-4215) Golang TTransportFactory Pattern Squelches Errors
[
https://issues.apache.org/jira/browse/THRIFT-4215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-4215.
Resolution: Fixed
Fix Version/s: 0.11.0
Committed.
> Golang TTransportFactory Pattern Squelches Errors
> -
>
> Key: THRIFT-4215
> URL: https://issues.apache.org/jira/browse/THRIFT-4215
> Project: Thrift
> Issue Type: Bug
> Components: Go - Library
>Affects Versions: 0.10.0
>Reporter: James Mouradian
>Assignee: Can Celasun
> Fix For: 0.11.0
>
>
> The current (as of 72ca60d) pattern for [TTransport
> factories|https://github.com/apache/thrift/blob/master/lib/go/thrift/transport_factory.go#L26]
> in Golang is
> {code}
> type TTransportFactory interface {
> GetTransport(trans TTransport) TTransport
> }
> {code}
> This causes issues, because some {{TTransportFactory}} implementations can
> return and error. Consider the
> [THttpClientTransportFactory|https://github.com/apache/thrift/blob/master/lib/go/thrift/http_client.go#L52],
> which as of of 72ca60d, includes the following snippet:
>
> {code}
> s, _ := NewTHttpClientWithOptions(p.url, p.options)
> return s
> {code}
> The call to {{NewTHttpClientWithOptions(...)}} call can throw errors. The
> resultant behavior is that {{nil}} is returned in place of a valid
> {{TTransport}}, with a {{nil}} error.
> The {{TTransportFactory}} interface (and associated use patterns) should be
> extended to include errors.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.
[ https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16036853#comment-16036853 ] Mario Emmenlauer commented on THRIFT-2221: -- I think this is the problem, but I do not understand the first '#if' well enough to solve it. Why is boost/scoped_ptr.hpp included if "__cplusplus < 201103L" ? I do not fully understand the multiple conditions in this file, maybe [~jking3] can help? > Generate c++ code with std::shared_ptr instead of boost::shared_ptr. > > > Key: THRIFT-2221 > URL: https://issues.apache.org/jira/browse/THRIFT-2221 > Project: Thrift > Issue Type: Improvement > Components: C++ - Compiler >Affects Versions: 0.9.1 > Environment: C++11 compilers with std::shared_ptr support >Reporter: Chris Stylianou >Assignee: James E. King, III > Labels: c++11, compiler, thrift > > Most modern compilers now have full support for std::shared_ptr when enable > with c++11 flags. It would be nice to have the option to generate code that > uses this instead of boost::shared_ptr. This would enable us to remove > another boost dependency, on the road to a dependency-free thrift library :) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (THRIFT-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.
[
https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16036846#comment-16036846
]
Mike Gresens edited comment on THRIFT-2221 at 6/5/17 11:57 AM:
---
Mario,
may be is not includes but used later:
{code}
+ #if __cplusplus < 201103L
+#include
+ #endif
{code}
and
{code}
+ #if __cplusplus >= 201103L && (defined(__clang__) || __cpp_alias_templates
>= 200704)
+using scoped_ptr = std::unique_ptr;
+ #else
+using ::boost::scoped_ptr;
{code}
Do the two #if's always match?!
# #if __cplusplus < 201103L
# #if __cplusplus >= 201103L && (defined(__clang__) || __cpp_alias_templates
>= 200704)
Mike...
was (Author: msg-72):
Mario,
may be is not includes but used later:
{code}
+ #if __cplusplus < 201103L
+#include
+ #endif
{code}
and
{code}
+ #if __cplusplus >= 201103L && (defined(__clang__) || __cpp_alias_templates
>= 200704)
+using scoped_ptr = std::unique_ptr;
+ #else
+using ::boost::scoped_ptr;
{code}
Does the two #if's always match?!
# #if __cplusplus < 201103L
# #if __cplusplus >= 201103L && (defined(__clang__) || __cpp_alias_templates
>= 200704)
Mike...
> Generate c++ code with std::shared_ptr instead of boost::shared_ptr.
>
>
> Key: THRIFT-2221
> URL: https://issues.apache.org/jira/browse/THRIFT-2221
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Compiler
>Affects Versions: 0.9.1
> Environment: C++11 compilers with std::shared_ptr support
>Reporter: Chris Stylianou
>Assignee: James E. King, III
> Labels: c++11, compiler, thrift
>
> Most modern compilers now have full support for std::shared_ptr when enable
> with c++11 flags. It would be nice to have the option to generate code that
> uses this instead of boost::shared_ptr. This would enable us to remove
> another boost dependency, on the road to a dependency-free thrift library :)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.
[
https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16036846#comment-16036846
]
Mike Gresens commented on THRIFT-2221:
--
Mario,
may be is not includes but used later:
{code}
+ #if __cplusplus < 201103L
+#include
+ #endif
{code}
and
{code}
+ #if __cplusplus >= 201103L && (defined(__clang__) || __cpp_alias_templates
>= 200704)
+using scoped_ptr = std::unique_ptr;
+ #else
+using ::boost::scoped_ptr;
{code}
Does the two #if's always match?!
# #if __cplusplus < 201103L
# #if __cplusplus >= 201103L && (defined(__clang__) || __cpp_alias_templates
>= 200704)
Mike...
> Generate c++ code with std::shared_ptr instead of boost::shared_ptr.
>
>
> Key: THRIFT-2221
> URL: https://issues.apache.org/jira/browse/THRIFT-2221
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Compiler
>Affects Versions: 0.9.1
> Environment: C++11 compilers with std::shared_ptr support
>Reporter: Chris Stylianou
>Assignee: James E. King, III
> Labels: c++11, compiler, thrift
>
> Most modern compilers now have full support for std::shared_ptr when enable
> with c++11 flags. It would be nice to have the option to generate code that
> uses this instead of boost::shared_ptr. This would enable us to remove
> another boost dependency, on the road to a dependency-free thrift library :)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (THRIFT-4220) Allow Service calls to be made using TSimpleJSONProtocol (using Simple JSON)
[
https://issues.apache.org/jira/browse/THRIFT-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Devansh Gupta updated THRIFT-4220:
--
Description:
https://github.com/degupta/human_readable_json_protocol
If we publish our Services/APIs as Thrift today you can't make requests using
simple Human Readable JSON. This means publishing our APIs to third party users
means they have to
1. Know how to use Thrift
2. Have all the Thrift definition files or the generated code
Or we have to build Libraries for each of the platforms we want to support.
This is not always possible.
I propose we do something like this:
{code}
exception SystemException {
1: i32 errorCode,
2: string message,
}
struct User {
1: string id,
2: string email,
3: string name,
4: i64 validatedAt
}
struct LoginResult {
1: string authToken,
2: User currentUser
}
service AuthenticationService {
LoginResult login(1: string email, 2: string password) throws(1:
SystemException err)
}
{code}
Request Format:
{code}
{
"method": "METHOD_NAME",
"arguments": { ... }
}
{
"method": "login",
"arguments": {
"email": "deva...@wi.co",
"password": "password"
}
}
{code}
RESULT:
{code}
{
"method": "login",
"result": {
"success": {
"authToken": "some_auth_token",
"currentUser": {
"id": "6a6c982b-62f9-46d2-aff9-bd3a1cdf43f9",
"email": "us...@wi.co",
"name": "user1",
"validatedAt": 0
}
}
}
}
{code}
This uses the JSON generated by the JSON Generator as "metadata" to figure out
the Field Keys and Types.
was:
https://blog.parsable.com/using-human-readable-json-endpoints-with-thrift-for-free-774ba505c893
https://github.com/degupta/human_readable_json_protocol
If we publish our Services/APIs as Thrift today you can't make requests using
simple Human Readable JSON. This means publishing our APIs to third party users
means they have to
1. Know how to use Thrift
2. Have all the Thrift definition files or the generated code
Or we have to build Libraries for each of the platforms we want to support.
This is not always possible.
I propose we do something like this:
{code}
exception SystemException {
1: i32 errorCode,
2: string message,
}
struct User {
1: string id,
2: string email,
3: string name,
4: i64 validatedAt
}
struct LoginResult {
1: string authToken,
2: User currentUser
}
service AuthenticationService {
LoginResult login(1: string email, 2: string password) throws(1:
SystemException err)
}
{code}
Request Format:
{code}
{
"method": "METHOD_NAME",
"arguments": { ... }
}
{
"method": "login",
"arguments": {
"email": "deva...@wi.co",
"password": "password"
}
}
{code}
RESULT:
{code}
{
"method": "login",
"result": {
"success": {
"authToken": "some_auth_token",
"currentUser": {
"id": "6a6c982b-62f9-46d2-aff9-bd3a1cdf43f9",
"email": "us...@wi.co",
"name": "user1",
"validatedAt": 0
}
}
}
}
{code}
This uses the JSON generated by the JSON Generator as "metadata" to figure out
the Field Keys and Types.
> Allow Service calls to be made using TSimpleJSONProtocol (using Simple JSON)
>
>
> Key: THRIFT-4220
> URL: https://issues.apache.org/jira/browse/THRIFT-4220
> Project: Thrift
> Issue Type: New Feature
> Components: Wish List
>Affects Versions: 1.0
>Reporter: Devansh Gupta
> Fix For: 1.0
>
>
> https://github.com/degupta/human_readable_json_protocol
> If we publish our Services/APIs as Thrift today you can't make requests using
> simple Human Readable JSON. This means publishing our APIs to third party
> users means they have to
> 1. Know how to use Thrift
> 2. Have all the Thrift definition files or the generated code
> Or we have to build Libraries for each of the platforms we want to support.
> This is not always possible.
> I propose we do something like this:
> {code}
> exception SystemException {
> 1: i32 errorCode,
> 2: string message,
> }
> struct User {
> 1: string id,
> 2: string email,
> 3: string name,
> 4: i64 validatedAt
> }
> struct LoginResult {
> 1: string authToken,
> 2: User currentUser
> }
> service AuthenticationService {
> LoginResult login(1: string email, 2: string password) throws(1:
> SystemException err)
> }
> {code}
> Request Format:
> {code}
> {
> "method": "METHOD_NAME",
> "arguments": { ... }
> }
> {
> "method": "login",
> "arguments": {
> "email": "deva...@wi.co",
> "password": "password"
> }
> }
> {code}
> RESULT:
> {code}
> {
> "method": "login",
> "result": {
> "success": {
> "authToken": "some_auth_token",
> "currentUser": {
> "id": "6a6c982b-62f9-46d2-aff9-bd3a1cdf43f9",
> "email": "us...@wi.co",
>
