On 24 January 2014 12:24, Jonathan Slenders <[email protected]>wrote:
> I agree with Gustavo. > > But: we should still have an option to use protocols when required. Maybe > just keep connect_read/write_pipe like it is, but change the constructor of > StreamReader and StreamWriter and decouple them. > > stdin = StreamWriter(proc.stdout, loop=loop) > > What I disliked and didn't understood about StreamReader and StreamWriter > when handling the master side of a pseudo pty, was the way they were > coupled. StreamReaderProtocol creates a StreamWriter instance. But in my > case it didn't work because it were different pipes. > StreamReaderProtocol only creates StreamWriter in case you pass it a client_connected_cb callback function. This is just a convenience, used by streams.start_server(). Outside of these special circumstances, StreamReaderProtocol does _not_ create a StreamWriter. So, for all intents and purposes, you may consider them decoupled. I think this is a side effect of StreamReaderProtocol and StreamWriterProtocol trying to be decoupled, one for each direction, when in fact some aspects of a socket are completely coupled. Sure, writing and reading are orthogonal. But connection_made() and connection_lost() are common to the whole socket, not to any particular direction. Maybe the class StreamReaderProtocol is now to so well named now, after having evolved some additional functionality (that was my fault). Also, I am not sure StreamReaderProtocol should even be public: streams.open_connection() and streams.start_server() both return to the application StreamReader and StreamWriter objects. StreamReaderProtocol should (and I think it does) remain completely hidden from the programmer; it is an implementation detail. Thanks, -- Gustavo J. A. M. Carneiro Gambit Research LLC "The universe is always one step beyond logic." -- Frank Herbert
