This is (sort of) OK as long you don't think about an include mechanism.
It works for my inheritance mechanism. I must admit that this mechanism
has a bit more overhead during serialization than an include mechanism,
because it is serialized in the standard Thrift way as composition.
??? 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.
What I meant was that the user does not have to specify the hash code when
he writes the first version because the compiler generates the value. But
when he renames a field he suddenly has to:
- add the old field name to his IDL, or
- find this 'weird' number to add to his IDL.
This might be the puzzling bit. I agree that this is easy to overcome but
so is manually specifying IDs from the start.
Do I hear a "My stuff is working. Let's not change it"?
I am not saying that. What I am saying is that 'it's a minor change' is
not a good reason to add it. The consequences for all the related code and
the possible incompatibilities have to be weighed against the advantages
before a decision is made.
And 'my stuff' is not working. I don't have the need for other clients
than Java-based ones at this moment, but I really want as many languages
as possible to be fully compatible so the software I write is open for
integration in the current and future infrastructure of my clients.
IMHO adding support for hash codes for IDs does not have enough advantages
to warrant a change in the syntax.
Adding support for inheritance to languages that do support it is
interesting however, but in this case I would keep the on-the-wire format
compatible with languages not supporting inheritance, i.e. write the
inheritance hierarchy out as composition.
Who has their own compilers? Care to share?
I am working on a compiler which takes a subset of the Thrift syntax and
generates:
- an HTML snippet with the syntax highlighted IDL used for showing
documentation about the services exposed on running servers
- metadata about the IDL files that are included by an IDL file (so all
dependencies can be determined at runtime, which is needed to make sure
the documentation of all used IDLs is shown)
- interfaces and implementations for structs (including hierarchies)
- interfaces for services
- classes containing constants and enumerations
- helper classes that can serialize the structs and services to and from a
Thrift protocol
- helper classes for RMI that allow me to switch to RMI instead of Thrift
- metadata telling the other RPC protocols (currently only XML-RPC) which
structures are allowed to be serialized, and which namespace and name must
be used for them on the wire
I want to use Thrift IDLs as the definition of services that I want to
expose using different protocols (Thrift, RMI, XML-RPC, (very simple)
SOAP, ...). I am hesitant of changes because I fear incompatibilities.
Incompatibilities would mean somebody would not be able to take my IDL,
generate code for a language (which may not have been supported when I
wrote the IDL), and communicate with my services exposed using Thrift. If
it comes to this I would have to drop support for exposing my services
using Thrift because it would become a maintenance nightmare. The only
thing I could do then is keep my own version of the IDL syntax based on an
early version of the Thrift syntax, and generate code for other protocols
where incompatibilities are less of an issue.
This is all a work in progress based on a framework for which I had to
write the structs and services manually. And for which it was cumbersome
to specify the metadata for each supported protocol. I could have used
SOAP to do the same but find Thrift so much easier. The ICE IDL, which is
similar to Thrift, is also an option, but license costs prevent from from
using it. Cisco Etch might be another option if I could find out more
about it.
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.
I am sorry I misunderstood you. What I don't understand is why you think
evolution requires changes to every client. This is only needed if you
want to delete the code that handles evolution on the server. If you don't
mind leaving the code running on the server you do not have to upgrade
existing clients (or their IDLs when you rebuild them for that matter).
I would like to stress that in my opinion compabitility is critical to the
success of Thrift. Given that there currently are a number of transports
and protocols with varying support in the languages that are supported,
the compatibility is not as high as I would want it to be. There is
already discussion of a new protocol, TDenseProtocol, I have proposed a
multiplexing socket transport, there is talk about asynchronous client
calls for which incomplete code is currently generated and that probably
requires a new transport, and it is not clear whether or not support for
reflective protocols is a primary concern.
--
Kind regards,
Johan Stuyts
