[
https://issues.apache.org/jira/browse/THRIFT-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chad Walters updated THRIFT-429:
--------------------------------
Fix Version/s: (was: 0.1)
0.2
Yes, I didn't really expect to get buy-off on this issue for 0.1 -- I just
wanted to make sure that folks read through the issue and understood that the
problem exists and continues to be a potential source of problems in the future.
I have the nagging suspicion that not fixing this problem will come back to
haunt the project in a big way at some point, but it sounds like we will likely
wait till we get there before we fix it. Deferring this will always seem like
the pragmatic choice until it becomes all too clear that it isn't.
Deferring to 0.2 for now...
> 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: Improvement
> Affects Versions: 0.1
> Reporter: Chad Walters
> Fix For: 0.2
>
>
> 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
