I like the idea, and although I don't fully understand the solution, I think it's trying to solve a similar problem to mine. Generating IDL is on my list too.
Does this method work for JVM built in scalar types as well as user class types? That would be closer to my current problem. Regards David M Bennett FACS Andl - A New Database Language - andl.org -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Stuart Reynolds Sent: Thursday, 10 September 2015 4:06 AM To: [email protected] Subject: Re: How best to add data types esp DateTime and Decimal Hi Jeff Once you go down the hole of writing wrappers for serialized types, you'll never come back -- the new type will be used repeatedly and you'll forever need to maintain a serialization wrapper API around your business services, which in very many cases is unnecessary -- the business service, in very many cases simply implements a client-facing interface, but deals with many of the same identical APIs and types. To me, this pretty much ignores the major benefit of thrift: 1 interface for a service, not many. The Swift API from Facebook provides a method to plugin coercions to perform serialization between any (JVM) type and a thrift IDL compatible representation (that it outputs) -- our serialized types are directly our nicely Spring/Jackson/... annotated Java and Scala business layer objects, and our client API interfaces is a strict subject of out business classes' interface. For us, this has avoided a lot of copy and paste and "same same API but different (in confusing ways)". We define an interface in scala, implement the API, and the rest is automated, including the IDL. If you're careful and define your various interfaces for different clients (eg. ClientV0Interace, ClientV1Interace, UnitTestInterace, DataBackendInterface ... ), to serve as views to a single service class implementation, this approach minimizes coding boilerplate (there is often none), and still leaves open the possibility to trivially insert an intermediate translation layer *if* that ever become necessary. This avoids the -- "not invented here so I'll make a wrapper to isolate myself from each and every API we interact with in case there are future unforeseen needs -- and lots of coding feel like progress" syndrome that I see a lot and, and that thrift helps to eliminate. ... just my two cents. I have a fork here which demos serialization of scala classes, scala containers and also can be used to marshall builtin and user-defined (i.e. not IDL generated) Java types. https://github.com/stuz5000/swift - Stu On Wed, Sep 9, 2015 at 4:31 AM, Jeff Nelson <[email protected]> wrote: > If you want to present your Thrift API directly to users, then you'll > probably need to create some struct that encompasses the information > you need for DateTime and Decimal. I'd go with a struct over a typedef > because the former gives you room to evolve in the future if necessary. > > With that said, I highly recommend that you DON'T expose your Thrift > API directly to users. Thrift is a GREAT framework for generating rpc > code in many languages, but it has to support the lowest common > denominator of languages features so that means it feels clunky and > unnatural in most languages. In the early days, Cassandra exposed > their Thrift API directly to users and it didn't work out well. > > Instead, I recommend that you wrap your Thrift API in language > specific drivers. This will allow you to give users libraries that > feel natural and adhere to the best practices of the language they > choose. Additionally, this means that you can have logic that > automatically converts whatever is the canonical DateTime class in > each language to the thrift struct you're expecting on the server. > > This approach has worked really well for ConcourseDB > <https://github.com/cinchapi/concourse>. For developing the language > drivers, thrift makes it so that we don't have to worry about the RPC > stack at all. We simply focus on the business logic of the driver > (which is generally the same across languages...just mapping various > types to the appropriate Thrift API calls). And our users benefit > greatly because they don't need to know about Thrift at all (this > greatly reduces the barrier to entry). We're also future proofed in > case we ever want to swap out thrift in the future (though I highly > doubt we'd do that because thrift is awesome). > > Cheers, > Jeff > > > > On Tue, Sep 8, 2015 at 10:12 PM, David Bennett <[email protected]> wrote: > >> In order to use Thrift as a remoting API for Andl I have to provide >> support for two data types: DateTime and Decimal. The question is >> what strategy to use that will produce the best outcome across common client >> languages. >> >> The DateTime data type is yyyy-mm-dd hh:mm:ss.xxx. It can use a wire >> format of i64 (100nsec units since Gregorian 0000, faster) or ISO-8601 >> (slower). >> >> The Decimal data type is (at least) 24 decimal digits of precision. >> It can use a wire format of 2*i64 (special format, faster) or a string >> (slower). >> >> The question is not about wire formats but how best to define and >> implement these types in Thrift for easiest consumption by client >> software in various languages. >> >> Is a typedef a useful approach? Or a named struct with a single field? >> >> How does one make it easy for the client to consume (given that most >> languages have some kind of preferred type)? >> >> Regards >> David M Bennett FACS >> >> Andl - A New Database Language - andl.org >> >> >>
