On Aug 26, 2008, at 14:38, Johan Stuyts wrote:
But it put the burden of managing sequence ids on the user. Which
also make the user require to know how Thrift works :)
What burden do you mean? I just have to make sure that each of my
sequence IDs is one higher than the previous one. If a remove a
field I simply comment it out to indicate that the ID has been used
but can no longer be used.
This is (sort of) OK as long you don't think about an include mechanism.
What if Thrift changed to use the hash method? Thrift lists the
ability to rename one of the fields without breaking existing
clients as a feature. A user might think that that's useful, so he
renames a field, doesn't know how IDs are generated, so does not add
the previous hash as the ID, redeploys one side of the system and is
disappointed because it does not work. Wouldn't you rather have that
he had learned about the IDs from the beginning so he understands
why renaming is possible?
??? Of course you can't change the hashing afterwards if you want to
stay compatible.
If you stick with that renaming works the same as before.
Come on! That's a tiny change in the grammar :)
IMHO it's not about your specific change, but all the changes that
have been proposed. Every change can have ripple effects for code
generation, transports and protocols for many languages. If these
changes are not kept in sync, it will result in lots of
incompatibility between languages/library versions. Although I have
no experience with Corba, I hate to see Thrift move in that
direction: a great idea which didn't catch on because of
incompatibilities.
Do I hear a "My stuff is working. Let's not change it"?
Also keep in mind that people may not like the current compiler
(including you because you would like a Java version)
Not because it's not java but rather because changing the code
generation is rather painful.
and/or the generated code (including me) and build their own
compiler in their preferred language. Changes to the IDL will then
also require these people to update their compiler.
Who has their own compilers? Care to share?
snip: example for evolution
Where will this end? You propose a simple transformation of two
fields. Should Thrift also be able to transform (intentionally
exaggerated):
- coordinates between Cartesian and Euclidean spaces
- angles between degrees and radians
- amounts between currencies
Yes, evolution of a service is hard. You should think about it and
handle it. A solution has already been proposed. Make 'version' and
'os' optional, add the optional 'versionandos', add code to handle
both situations to the server, and redeploy the server. Existing
older clients will continue to work without a problem, and once all
clients have switched over you can drop 'version' and 'os'.
I do not see how this is a limitation of Thrift. In my opinion this
is one of its greatest strengths.
Please re-read what I wrote. I was not suggesting to have this
included into Thrift. But this still is a common problem. Question is
whether there is a way to do version migrations like this somewhere
central instead of having that in every client.
cheers
--
Torsten
