One other thing that I forgot to mention is that I would be in favor of adding a new message type for asynchronous calls, even though it would changing the wire format and could be kind of a pain to roll out.
--David David Reiss wrote: > 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. >
