thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick R <rick.richard...@gmail.com>
Subject Re: Some thoughts about changes to Thrift
Date Thu, 05 Mar 2009 21:38:37 GMT
I'm for it, as long as there is a --non-strict compiler mode which allowed
older messages (but printed a warning)


On Thu, Mar 5, 2009 at 4:34 PM, Bryan Duxbury <bryan@rapleaf.com> wrote:

> Hey guys,
>
> I wanted to run an idea past everyone. There was an email to the list a few
> days ago about Ruby enum validation of implicit values that got me thinking
> that Thrift allows a lot of design decisions that aren't really in line with
> best practices. In order to achieve respectable forward and backward
> compatibility, one of Thrift's main stated goals, there are a bunch of
> things you *should* do, but that aren't enforced. For instance, implicit
> enum values and optional field ids in structs and on service method
> parameters. These are things that a careful Thrift user should never really
> do, but since they aren't enforced, there's risk for new users to do the
> wrong thing.
>
> My idea is that we should change the Thrift IDL essentially to force these
> best practices on users. The obvious benefit is that even a new user will be
> pushed to do the right thing, avoiding potential pitfalls in writing their
> definitions. The downside is that .thrift files will be a little more
> verbose on average. (It's also a non-backwards-compatible change, so
> everyone will have to update their Thrift definitions.) At least in my mind,
> it seems like the positives would outweigh the benefits, and it would free
> us up to do things like get rid of autogenerated negative field ids.
>
> What are everyone's thoughts on this idea?
>
> -Bryan
>



-- 
We can't solve problems by using the same kind of thinking we used when we
created them.
   - A. Einstein

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