thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Slee <>
Subject RE: transport and protocol separation
Date Wed, 08 Oct 2008 22:32:38 GMT
This is a good question. Originally, the interface looked like what you
described, read/write methods took in both a protocol and a transport,
and the protocol methods (i.d. readInt()) all took in a transport

The reason we changed this is to make a clear contract that transport
interfaces are to be owned by one protocol. This allows for the
implementation of more efficient, stateful protocols. For instance, the
JSON protocol can read ahead in a transport. Individual calls to
read/write*() need not actually read/write to the transport. Rather,
they can use an internal buffer if this makes sense in the context of
the protocol's implementation. There is also a guarantee that they are
working on the proper transport, since it is owned by the protocol.

Conceptually, the Protocol is just reading through the Transport, as you
describe. This interface design communicates how a Transport is meant to
be used exclusively by one Protocol object that wraps around it, and
that is is acceptable for protocol calls to have side effects that may
affect future usages of the Transport.


-----Original Message-----
From: Torsten Curdt [] 
Sent: Monday, October 06, 2008 1:36 AM
Subject: transport and protocol separation

I am wondering what was the rational behind

  public interface TBase  {
    void read(TProtocol iprot) throws TException;
    void write(TProtocol oprot) throws TException;


  public interface TBase  {
    void read(TProtocol iprot, TTransport itrans) throws TException;
    void write(TProtocol oprot, TTransport otrans) throws TException;

Which of course would require to pass in the transport on the protocol

  TStruct readStructBegin(TTransport itrans) throws TException;

and so on.

Reading with protocol from transport makes more sense to me than reading
from a protocol.

See what I mean? Just wondering...


View raw message