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
