> It is straightforward enough, but it feels a bit like doing OO without OO. ... > Looking a bit at the binary protocol, it seems this can be implemented > without altering the protocol specification; instead of sending the > function name "setServerAdmin", you send > "virtual.hostname/setServerAdmin". So it's doable in a > backward-compatible fashion, but it will require a bit of work. the current semantic model for Thrift is that you are calling methods on services, not objects. If the issue is "OO style", then the problem is that the opaque object handle requires a lot of state to be stored between requests, which is pretty counter to the way I think of Thrift (seems more CORBA-y). I recommend using Todd's suggestion of a 64-bit int as an identifier. (This would be easy to wrap in a library.) If the issue is virtual hosting, there is no current support for this. I'm not opposed to it, but you are correct that it would take a fair amount of work.
>>> Second, it often is very useful to know where a request came from and >>> how we got here. For example, it might be beneficial to limit the >>> amount of requests per second per source IP, and for that we'd need >>> the context the call came through. This could also be used to cache >>> data on a per-client basis, and is useful for logging. Is there an >>> easy way to get this from inside the interface implementation in your >>> program? >> To implement this you'd have to subclass the server. I'm not very >> familiar with the cpp bindings, but I don't imagine it would be >> extremely difficult. > Looking at the generated cpp code, there doesn't seem to be any > propagation of transport or protocol information. This is generally a > good idea, except I sort of need it ;) Changing this would seem to > require changing the thrift-to-cpp compiler, which is likely quite a lot > of work. I can't simply override parts of the server and set a global > variable; doing so would not be thread-safe. Subclassing the server and including application logic in the server is probably the simplest way. We also have some callback set up, but they only get a limited amount of data, they cannot affect processing, and they cannot communicate with the handler. Ben Maurer and I came up with what I think is a pretty clean way to pass this data to the handler, but it would be backwards incompatible at the source level, and would also be a fair amount of work. --David
