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

Bryan Duxbury commented on THRIFT-429:
--------------------------------------

I'm with David on this one. It sounds like it'd be a lot of pain for not that 
much real benefit. Even if we were going to solve this problem, it's way too 
late in the release cycle to go for something this big. 

> 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.1
>
>
> 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.

Reply via email to