[jira] [Comment Edited] (THRIFT-2457) fbthrift float

["Jens Geyer (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976226#comment-13976226 ] 

Jens Geyer edited comment on THRIFT-2457 at 4/24/14 2:17 PM:
-------------------------------------------------------------

EDIT:
-We are still at 0.9.x, so we have a certain freedom here, I think.- No, we haven't. Thrift is used widely in productive environments, and that's the only thing that matters here.
-At least it does not break compatibility.- That's not correct either. Of course it does, as Ben pointed out.

{quote}
What about a compiler warning?
{quote}

{quote}
Maybe scan the entire .thrift file for usages of float. If float is used, bump the protocol version
{quote}

What about combine both into one? What I have in mind is something like this:

 * The compiler has a built-in maximum version, which is simply the *highest* version known to that Thrift compiler/library version. The user can override this upper limit by adding a command line switch, such as {{-maxprotversion 2}} to any lower version of his choice. This is to provide compiler-checked backwards compatibility (details below).

 * The compiler scans the IDL and notices usage of new types, such as {{float}}. During that process, the compiler also keeps track of the lowest possible protocol version, starting with today's current version {{VERSION_1}}. If a type is not supported by that version, the following two-step algorithm is performed:
   (1) the minimum required version number is increased to the appropriate value
   (2) if the user restricted the highest allowed version by means of {{-maxprotversion N}} to something lower as the new minimum version requires, an error is omitted. 
   
 * The compiler (somehow) writes the detected minimum protocol version into the generated code, to be used when the data are serialized. 
 
 * The version check is improved from an exact match into a range comparison {{min < version < max}}, where the lower and upper limits are the version range the currently used compiler/library code is able to handle. This way, a version 3 library would/should still be able to read a version 2 wire format. Furthermore, even a radically incompatible version break could still be done by increasing the lower limit of the accepted versions range.
    
   
Open problems:
 - there is some part in the code, saying that {{VERSION_2}} is reserved to the dense protocol. It seems not to be used actively, so dense itself is not so much the issue here, the more general question is, whether we will have such things in the future that cannot be determined alone by parsing the IDL, and how to deal with it?
 - because the written version is variable, this part needs to be opened and made accessible in the library code, as Ben already pointed out above.
 




was (Author: jensg):
We are still at 0.9.x, so we have a certain freedom here, I think. At least it does not break compatibility.

$0,02

> fbthrift float
> --------------
>
>                 Key: THRIFT-2457
>                 URL: https://issues.apache.org/jira/browse/THRIFT-2457
>             Project: Thrift
>          Issue Type: Sub-task
>          Components: Build Process, C++ - Compiler, C++ - Library, Test Suite
>            Reporter: Roger Meier
>            Priority: Minor
>             Fix For: 1.0
>
>
> I'm interested into the fbthrift FLOAT data type.
> Which languages are supported?



--
This message was sent by Atlassian JIRA
(v6.2#6252)