Java Transport Library Classes

[Randy Abernethy <Ra...@rx-m.com>]

Hello All,

I have a number of questions I would like to pose to the group centered 
on the Java Transport Library. Here is a class sketch of the 1.0 Java 
transport package to help illustrate the questions.

http://rx-m.com/assets/JavaTransports.jpg

1.Do TFileProcessor and its relatives (TFileTransport, TSeekableFile, 
TStandardFile) belong in Thrift?

oTFileProcessor is in the transport package but it is not a transport, 
it is a replay utility for file archived messages and does not strike me 
as a serialization library or RPC frameworkcomponent

oTFileTransport does not support writing and appears to be fairly 
purpose built to support TFileProcessor

oTSeekableFile is the interface between TFileTransport and TStandardFile

oTStandardFile is not a TTransport and appears purpose built to support 
TFileProcessor

oNone of these classes have tests

oNone of these classes are used anywhere else in the Thrift master

oPerhaps these classes belong in contrib or the user's private lib

2.Do we need both TFramedTransport & TFastFramedTransport?

oIf we have a fast one why would someone use the slow one?

oPerhaps we should make the fast one the TFramedTransport and provide 
the option of deleting the buffers after I/O if folks want the old 
TFramedTransport behavior

3.Should support classes be represented at the top level of the Java 
transport library?

oIt might make the transport library a bit easier to digest if the top 
level support classes were moved into the classes they support

oThe following classes could be moved into TFastFramedTransport:

§AutoExpandingBufferWriteTransport

§AutoExpandingBufferReadTransport

§AutoExpandingBuffer

oThe following classes could be moved into TFileTransport:

§TSeekableFile

§TStandardFile

oThese changes would leave us with classes of interest to end users at 
the file level

oThese support classes are not used within Thrift outside of the 
suggested enclosing class

4.Why is THttpClient not THttpTransport?

oThe "Client" moniker is attached to Thrift IDL Compiler generated 
Service-Client classes, which makes the name THttpClient confusing

oTHttpClient is really an end point transport derived from TTransport, 
many looking for this functionality would seek THttpTransport if not 
familiar with the http specific naming

oI realize this change would break the world, and that other languages 
use the client suffix in the same way, is this just an anachronism or 
have I missed something

The only motivation around any of these thoughts is that of improving 
consistency and clarity, making Thrift easier to use and understand as 
the 1.0 release approaches. If any of these thoughts make sense I would 
be happy to create the necessary patches.

Best regards,
Randy