[
https://issues.apache.org/jira/browse/THRIFT-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14040007#comment-14040007
]
Randy Abernethy commented on THRIFT-2586:
-----------------------------------------
Hey Jens,
I agree heartily with your assessment. When I first came to Thrift I was
particularly interested in serializing structs across languages. I uncovered
little documentation and worse once I figured out the lib elements in one
language I found I had to relearn everything in the next language.
A semantic abstraction and consistent conventions/names across languages would
be a significant improvement for Thrift. I re-post below an email I sent in
this regard a year or so ago focused on the Java lib.
This also ties into the discussion we had a year back regarding the features
one would expect in a fully supported thrift language.
I modeled the TSimpleFileTransport in Java after the TSimpleFileTransport in
C++ specifically to allow simple file writes in both languages. I really think
there should be a single TFileTransport class in every language and it should
be "simple" to use but offer the necessary features required by users
-Randy
--------------------------------
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?
- TFileProcessor 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
- TFileTransport does not support writing and appears to be fairly purpose
built to support TFileProcessor
- TSeekableFile is the interface between TFileTransport and TStandardFile
- TStandardFile is not a TTransport and appears purpose built to support
TFileProcessor
- None of these classes have tests
- None of these classes are used anywhere else in the Thrift master
- Perhaps these classes belong in contrib or the user's private lib
2. Do we need both TFramedTransport & TFastFramedTransport?
- If we have a fast one why would someone use the slow one?
- Perhaps 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?
- It might make the transport library a bit easier to digest if the top level
support classes were moved into the classes they support
- The following classes could be moved into TFastFramedTransport:
** AutoExpandingBufferWriteTransport
** AutoExpandingBufferReadTransport
** AutoExpandingBuffer
- The following classes could be moved into TFileTransport:
** TSeekableFile
** TStandardFile
- These changes would leave us with classes of interest to end users at the
file level
- These support classes are not used within Thrift outside of the suggested
enclosing class
4.Why is THttpClient not THttpTransport?
- The "Client" moniker is attached to Thrift IDL Compiler generated
Service-Client classes, which makes the name THttpClient confusing
- THttpClient 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
- I 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
- These changes could be made leaving deprecated aliases of the old names in
place to avoid breaking the world
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
> Towards a more consistent FileTransport naming scheme
> -----------------------------------------------------
>
> Key: THRIFT-2586
> URL: https://issues.apache.org/jira/browse/THRIFT-2586
> Project: Thrift
> Issue Type: Improvement
> Components: Wish List
> Reporter: Jens Geyer
>
> I just did some research across the /lib folder too find out, what kinds of
> file transports are supported by the various languages. This is what I found:
> Cocoa
> - TNSFileHandleTransport
> C++
> - TFileTransport
> - TSimpleFileTransport
> - TPipedFileReaderTransport
> D
> - TFileReaderTransport / TFileWriterTransport
> Erlang
> - thrift_disk_log_transport.erl
> Java
> - TFileTransport
> - TSimpleFileTransport
> Python
> - TFileObjectTransport
> Obviously, we have a somewhat inconsistent naming scheme. Next, the
> difference between a {{TFileTransport}} and a {{TSimpleFileTransport}} is not
> deductable by the name, and it is not intuitively clear what transport to use
> in which case without looking at the implementation of both transports.
> If we stick with Java as an example, {{TSimpleFileTransport}} just means,
> that this is the *real* file transport, while the {{TFileTransport}} should
> be called {{TFramedChunkedFileTransport}}, because that's what it is.
> Once we found a good naming scheme, all other file transports should be named
> after that scheme, as appropriate. This makes it more easy to the Thrift user
> and prevents errors due to incompatible transports caused by bad names
> (THRIFT-2582).
> I'd like to hear your opinions.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
