Hi Markus,

I was thinking about the design issue you put up regarding how Socket is passed as an argument to TcpSocketBuffer. I have some ideas which I’d love to discuss with you and with others. Right now we have a relation like this:

    -------------------  ----------------
    | SocketTransport |  | SocketBuffer |
    -------------------  ----------------
 socketConnected()   |    |
 socketDisconnected()|    |
 socketError()       |    |
 socketRead()        |    |
 socketWritten()     |    |
                     |    |
 connectToHost()     |    | read()
 disconnectFromHost()|    | write()
 abort()             |    |
                   ----------
                   | Socket |
                   ----------

Since SocketTransport only handles the connection part and delegates the data part to SocketBuffer, I was thinking that the following could be a sounder design:

               -------------------
               | SocketTransport |
               -------------------
                     |    |
   --------------------  ----------------
   | SocketConnection |  | SocketBuffer |
   --------------------  ----------------
 socketConnected()   |    | socketRead()
 socketDisconnected()|    | socketWritten()
 socketError()       |    |
                     |    |
 connectToHost()     |    | read()
 disconnectFromHost()|    | write()
 abort()             |    |
                   ----------
                   | Socket |
                   ----------

This way SocketTransport will simply delegate the implementation of the Transport interface to SocketConnection and SocketBuffer. Which makes me wonder whether it would make sense or not to split the Transport interface in two separate interfaces – Connection and Buffer? I’m not certain what implications such a split might have…

Another thought I just got today was that this Transport abstraction would probably also work for a File! We could have a FileTransport that read and writes to a file (dumping packets to files could be rather easy) and sends a socketError() or socketDisconnect() when the end of file is reached.

Another nice functionality would be performing data encoding decoding (e.g. deflate, gzip, base64) at the Transport level. We might add a Codec in between SocketTransport and SocketBuffer, or intergrate the Codec with SocketBuffer or maybe even use the Decorator design pattern to create a EncodedTransport class that runs incoming and outgoing data to a Transport through a Codec.

Best regards,

Peter