[web-devel] Re: Lazy simpleHTTP

[Paul Brown]

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 at gmail.com