> I do feel however that uniformity across languages is less important. > [...] > People working on multiple languages might object though. I do. :)
>>> - Remove the Client and Processor classes from generated code of >>> services >>> so server and client implementations have more freedom concerning how >>> (service and) function selection information is communicated and >>> processed, and how I/O is handled. See below. >> I don't think that these need to be removed. They are the most common >> use >> case by far, but it is completely possible to replace them. > > It just does not feel right to me where this code is located now. The > processing can differ significantly between implementations. Providing one > method of request processing in the generated code is confusing. Client > and server implementors might hesitate to ignore the code and write their > own request processing, because they feel that would be like working > against the framework. > > Also if improvements to the request handling have to be made, all > generated code has to be regenerated. If the code is moved to the client > and server implementations only the library needs to be upgraded and all > deployed code benefits. > > To be able to replace Client and Processor other interfaces and classes > are needed (i.e. the Service and Function types I described earlier). > Again I feel it would be confusing if the generated code contained both > Client and Processor, and Service and Functions. I disagree with this. The processor provides a simple interface for selecting a function to call, deserializing its arguments, and serializing its return value. It implements a part of the protocol, so replacing can potentially break wire-compatibility. I don't think that it is a component that should be replaced lightly. >>> - Add an interface to the generated code and add support classes for >>> doing >>> asynchronous calls (i.e. support for sequence IDs). See below. >> This can be done without changing any of the existing interfaces. > > From the perspective of a caller of a function it does not look this way. > How do I sent a request for which I either: > - poll for the result, or > - get notified by an event. > > Each client implementation has to provide its own mechanism now. It would > be nice if Thrift provided standard interfaces (for polling, notifications > or both) for handling asynchronous calls. I meant that this could be added in addition to the current synchronous interface. The problem with having a "standard" interface for asynchronous calls is that every language has a different way of expressing callbacks and asynchronous I/O. This doesn't mean that we shouldn't try to present a reasonably uniform API, but it does mean that it is a fairly ambitious cross-language project. >>> The extra layer of transports around I/O streams seems redundant to me. >> I would be open to dropping the Transport interface in favor of something >> built into Java, but I am not able to find anything that supports both >> input and output. For example, it looks like java.net.Socket extends >> Object and implements no interfaces. > > What about using 'InputStream' and 'OutputStream'? A protocol can be given > the streams which it will read from and write to directly. > > I think it is even possible to split protocol into two interfaces: > InputProtocol and OutputProtcol. These are both possibilities (and I think TProtocol already supports input and output transports). The downside is that it eliminates the nice property that you have just one object that manages all of your communication with the other side. --David
