Thanks, Roger! I'm also posting this to the dev list, because I think that may be more appropriate than user@. The json generator is awesome (any estimate on when it will be merged?), but that's not really what I was working on. The goal here is to ready an aribrary JSON message as thrift data.
Pete On Wed, Oct 8, 2014 at 11:47 AM, Roger Meier <[email protected]> wrote: > Hi Peter > > Yes, JSON is worth to add and I see an option by using json schema as > mentioned here: > https://issues.apache.org/jira/browse/THRIFT-2360 > > best! > -roger > > > Quoting Peter Neumark <[email protected]>: > > Hi all, >> >> At Prezi, we currently use Thrift for a lot of the internal communication >> between services. A lot of engineers would like to keep using HTTP + JSON >> as means of communicating between services, but with some sort of schema. >> >> After evaluating several alternatives, the best idea we had so far was to >> use the thrift IDL as the schema, and beef up the existing >> TSimpleJSONProtocol code to read arbitrary JSON messages. >> >> What I'm most interested in is whether or not someone else is already >> doing >> this? >> >> I have a very early stage python implementation of such a protocol here: >> https://github.com/neumark/thriftmodel/blob/master/thriftmodel/ >> TFlexibleJSONProtocol.py >> >> We'll probably create an implementation for Java as well. >> The most difficult issue with reading JSON is that a lot of existing JSON >> protocols allow for several different types in a field. My solution was to >> have an "unboxed union". To illustrate this with an example, if we accept >> the following messages: >> >> {"id": 1, "expires": 32324234234} >> {"id": 1, "expires": "2014.10.07 10:34"} >> {"id": 1, "expires": false} >> >> Then our Thrift definition would be >> >> // Note: this is an unboxed union >> union { // or struct in my implementation because python has no union yet >> 1: i64 unix_timestamp, >> 2: string date_string, >> 3: bool expiration_switch >> } >> >> struct msg { >> 1: i64 id, >> 2: expiry expires >> } >> >> The "expires" field must be read "unboxed" so to speak. >> What's the best option for encoding this in the thrift IDL? >> Has anyone considered adding annotations to the IDL for similar purposes? >> >> Thanks, >> Peter >> > > >
