You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by Alexander Shigin <sh...@rambler-co.ru> on 2008/11/08 21:56:49 UTC

Re: Protocol umbrella proposal

В Чтв, 30/10/2008 в 19:10 -0700, Mark Slee пишет:
Sorry for a long term before response.

> Also, the version numbers are more defensive than anything else. One
> of Thrift's design values is to be as "dumb" as possible in situations
> like this and to avoid smart dynamic checks/negotiations in favor of
> simple, straightforward procedures that are optimized for performance.
> Breaking protocol changes should generally be far and few between.

It's near impossible to make any change in protocol and keep compatible
with previous versions.

> What is the major issue that you're running into that's bringing up
> this problem? Do you have examples other than adding true/false types?
> Doesn't TBinaryProtocol already support reading/writing the bool type?
> Do you mean offering a different implementation?

I've got two examples:

any type (THRIFT-122, https://issues.apache.org/jira/browse/THRIFT-122 )
If old software reads field with "any" type old protocol can't skip the
field: protocol hasn't any clue to determine size of field. So we get
desynchronization and even can't determine end of struct.

bool type spends an extra byte. If we try to make two separate types
"false" and "true" to reduce network usage it breaks backward
compatible. But if we accept an umbrella protocol it will be possible.
So it will be possible to switch to a protocol like protocol from
THRIFT-110 without any changes to client or server code.