thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James E. King III (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (THRIFT-429) Make binary a full-fledged type of its own
Date Thu, 03 Jan 2019 03:38:00 GMT

     [ https://issues.apache.org/jira/browse/THRIFT-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

James E. King III updated THRIFT-429:
-------------------------------------
    Fix Version/s:     (was: 1.0)

> Make binary a full-fledged type of its own
> ------------------------------------------
>
>                 Key: THRIFT-429
>                 URL: https://issues.apache.org/jira/browse/THRIFT-429
>             Project: Thrift
>          Issue Type: Sub-task
>          Components: Compiler (General)
>    Affects Versions: 0.1
>            Reporter: Chad Walters
>            Priority: Major
>
> From the point of view of the protocol abstraction, the 'binary' type looks like a full-fledged
type but under the covers the implementation is such that the wire format encodes 'string'
and 'binary' types with the same type code. I'd like to see 'binary' become a full-fledged
type instead.
> This wart of the implementation has at least one strange and unexpected implication:
protocol implementations must be careful that 'string' values can be skipped properly by way
of the readBinary() method. This affects protocols where the wire format of 'string' is different
from the wire format of 'binary'. I encountered this problem when implementing the JSON protocol.
> I am not sure if there are other implications of this wart -- it's possible there are
others that have not been surfaced yet.
> This is unfortunately a backwards-compatibility breaking change and has implications
for those who have large investments in persisted Thrift structures. I realize that the down-side
here so far is fairly limited -- the JSON protocol was able to work around this without too
big a problem. We had discussed this a year ago and got some level of agreement that we wouldn't
do this until there were some other significant backwards-compatibility breakage.
> However, it only becomes harder over time for such a change to be made, as more people
persist more and more Thrift data. I think it is pretty clear that in retrospect we would
not have designed things such that the same type code is used on the wire for 'string' and
'binary'. I wonder if the current users of Thrift who would be impacted by this now would
agree to take on the pain of this change now so that future users will not have to go through
this pain (also, their own pain might be lessened by doing this sooner rather than later).
> I am raising the issue and targeting for 0.1 to prompt a little bit of discussion.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message