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.
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?
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.
Also keep in mind that people may not like the current compiler (including
you because you would like a Java version) 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.
As the model would be flattened we could also just call it an include
mechanism. It's not really inheritance in the OOP way.
My compiler detects a specific field in a struct as a declaration for
inheritance: must have '1' as the ID and 'extendedObject' as the name. The
Java code it generates is an inheritance hierarchy, but the serialization
to and from protocols will be compatible with the declarations as found in
the IDL:
struct PingParameters
{
1: nl.zybber.lib.stdlib.procedures.common.ProcedureBaseParameters
extendedObject
...
}
Generates this class:
class PingParameters extends ProcedureBaseParameters
{
...
}
This class will be serialized as struct 'PingParameters' with field 1 of
type struct 'ProcedureBaseParameters'. Anybody who takes my IDL and
generates code from it will be able to communicate with my services.
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.
The only thing that might be useful to do automatically is automatic
transformation of a smaller to a bigger datatype. For example: the old
version used bytes, but the new version accepts 16-bit integers.
--
Kind regards,
Johan Stuyts
