Randy, There is a different way that one could allow for Thrift IDL metadata to be accessible at protocol-time (which is really what I'm proposing): one could pass the entire metadata information the protocol constructor. Pros & Cons:
(1) for the config-file use-case I described, this is enough. (2) But this is NOT enough for the "human-readable wireline for Thrift servers". I've noted that several times, people have asked for a JSON wire-format that they could use to invoke Thrift servers, that is .... well, more "normal JSON". And this is not advanced by passing the IDL metadata to the T<NiceJSON>Protocol constructor, b/c that constructor is invoked from the TProtocolFactory, and there's structure in place for figuring out the right metadata to pass. BUT (3) one COULD imagine a new Thrift RPC stack, which would be initialized with IDL metadata, and which would pass the right metadata down to the Protocol instances at creation time. This seems like much more work than the small change I'm proposiing. I -DO- see that the biggest con of what I'm proposing, is that it MIGHT break source-code compatibility for all previously-generated Thrift code. I think this is remediable in the following way: (a) add a new method readFieldBegin2(....) where the metadata is passed as a (possibly NULL) pointer (b) old generated code continues to call readFieldBegin() (c) old protocol impls merely define readFieldBegin2() to call readFieldBegin() (d) new generated code calls readFieldBegin2 (with that metadata) (e) and new protocols like TNiceJSONProtocol and TCompactTextProtocol would implement readFieldBegin2 to do what I described in my first note, while implementing readFieldBegin() (the old method) to panic with an error-message. Uh ... this seems to solve the source-code compatibility issue. I don't have a good understanding of what level of binary-code compatibility Thrift promises, so I can't comment on that. Thoughts? --chet--
