I agree with Bryan that we should break these up into separate JIRA issues ASAP. I also think that is important to think of some things in a cross- language manner. For example, using an options object for constructors doesn't really require any cross-language consideration, changing the TProtocol interface requires some because it is best to keep uniformity, and changing the message protocol requires a lot because it is necessary to keep interoperability.
> - A different set of functions for TProtocol so protocol implementations > have more flexibility (For example see > https://issues.apache.org/jira/browse/THRIFT-110 (Changes to the IDL would > still be required to be able to implement a compact format)). I think this has to be considered in a cross-language way. The fact that TProtocol has the same interface in each language means that it is much easier to code up the same protocol in each language. > - Properly supporting optional members of structures. I think we can port the C++/JavaBeans code to the normal Java generator without redesigning anything. > - Removal of the name when writing the beginning of the structure as > nobody seems to need this > (https://issues.apache.org/jira/browse/THRIFT-8). There is no need to hang > on to obsolete constructs and confuse new users. This is currently used in the TDebugProtocol in C++ (which produces human-readable representations of Thrift structs) and the TSimpleJSONProtocol in Java which is a lossy write-only protocol that produces easily-consumable JSON strings for scripting languages. > - Replace base classes with interfaces so implementations that want to do > things differently do not have to extend the base class awkwardly. For > example: TProtocol and TServer. +1 > - Refactoring of strange constructs in the current API. For example: the > 'getTransport(TTransport)' method of TTransportFactory is used as a > transport transformer in addition to being used as a factory. When used as > a factory method the parameter makes no sense. Yeah, I think this is just poor naming. The TTransportFactory interface is used to give us a uniform way of wrapping a transport. > - 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. > - 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. > - Drop the many constructors of a number of classes and replace them with > a single constructor taking an options object. I'm fine with this. > - Drop the 'T' prefix of types as this is not customary in Java. As I said when this was suggested for Ruby, I think that the T prefix makes it easier to import classes without name collisions and distinguishes specific interfaces like TProtocol from generic names like "Protocol" or "Binary". > Another example that could be built is a client that requests the mapping > of (services and) functions to IDs from the server, so invocation of a > particular function does not require the sending of the (service and) > function names. Instead a few bytes are all that is needed to select a > function. This is very difficult to do now because the Client and > Processor classes have control over the information of the message being > sent. This is something that we discussed a few months ago when we had a meeting about creating a more compact protocol. It think the generic term we used to describe it was "out of bad exchange of IDL information". I think it is a great idea, but it has to be implemented cross-language. > Drop transports > =============== > All servers currently require a transport, but the internal workings of a > server are closely tied to a specific transport. Why have servers work > with wrappers around sockets instead of working with sockets directly? This is not the case. For example, the TNonblockingServer in C++ accesses sockets directly (via libevent) and hands TMemoryBuffers to the Processor. The purpose of the TServerTransport is to make it easier to implement servers that are less I/O-aware (like the TThreadPoolServer) in a uniform fashion. > The only thing that needs to be handled is 'TFramedTransport' because this > is a decorator. In my opinion it may be better to implement it as a > protocol decorator which frames messages. I disagree. Having it as a transport means that it works across protocols and that it can be handled at a lower level. > Asynchronous interface > ====================== > (Does anyone have a better name than 'asynchronous functions' so the > 'async' keyword and sequence IDs cannot be confused?) I've thought a lot about this and I haven't been able to come up with anything good. See https://issues.apache.org/jira/browse/THRIFT-136 > 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.
