Hi, Henning --
I'll continue my thread ... I think it is best to build the lazy stream on top of Network.Socket, not Network.TCP, since the first one does not buffer and the second one does. Since my lazy stream reads the entire source content into a single String lazily, I already have a buffer. In order to not duplicate code, I'd like to introduce a hidden module Network.TCP.Private with open and close methods, which can then be used by Network.TCP and Network.Stream.Lazy. Alternatively I could add a new public module for unbuffered TCP transfer. I think this would be even cleaner. However, I had to name the new module, say, Network.TCP.Unbuffered and the module names Network.TCP.Unbuffered+Network.TCP are somehow the wrong way round compared to Network.TCP+Network.TCP.Buffered. Maybe I should name them Network.TCP.Unbuffered+Network.TCP.Buffered and re-export the latter one in Network.TCP. Have such changes a chance to get included into HTTP package?
I'm still a little lost as to why this is necessary and/or desirable. Some (if not all) of your use cases would be achievable via proper use of HTTP protocol features (100 Continue, Conditional GET, etc.), and it is a question of whether those are well supported by the current implementation. For the laziness in handling response bodies, I think you'd actually want to expose an iteration semantic implemented on top of HTTP chunked encoding and ranged requests, and that would live at a higher level in the stack than the TCP layer. Just $0.02 for you. Paul Brown paulrbrown@gmail.com