Re: Chunked Encoding

[Daniel Hartwig]

On 6 May 2012 12:52, Ian Price <address@hidden> wrote:
> Well, what I meant is a port that would be layered over the top of
> another. Soft ports or custom binary ports would be used to implement
> it. (Is there a reason (effiencywise) to prefer one over the other?)
>

Intuitively I would think custom binary ports are more efficient, but
I haven't tested this.  However, back when I was experimenting with
this I ran in to trouble getting the binary port to close it's base
port -- the soft port interface was much nicer for this.

>
> Basically, my interface right now is
>
> (make-chunked-input-port port) -> input-port
> (make-chunked-output-port port) -> output-port
>
> These operate pretty much as you'd expect. The port returned from
> 'make-chunked-input-port' reads whole chunks from its argument port, and
> maintains a buffer, from which it can satisfy smaller reads.
> The port returned from 'make-chunked-output-port' buffers up the writes
> and writes a whole (properly formatted) chunk on 'force-output'.
>
> The only behaviour I'm not entirely sure of is what happens on
> close. Let's be more concrete:
>
> (define a <port>)
> (define b (make-chunked-input-port a))
> (close-port b)
>
> What is the state of a?
>
> (define c <port>)
> (define d (make-chunked-output-port c))
> (close-port d)
>
> Likewise for c.
>
>
> I think common practice in things like Java's BufferedReader would be to
> have a be closed when b is. This may be undesirable since we could wish
> to continue using the socket. On the other hand, once you start layering
> ports, it is convenient to have the higher layers close the lower
> layers. I think it might make sense to have a keyword argument,
> #:dont-close? (or something), that specifies this behaviour, defaulting
> to close.
>
> c seems less clear to me. Again, once you have multiple layers, it would
> be convenient, and it would properly handle any inner state saved up.
>
> Any thoughts on this?
>

A quick glance at your latest patch and it looks pretty good. I'll
give this a bit of a workout during the week.

Having #:keep-alive? is great.  At some layers you would want it,
others not.  With a chunked-gzip transfer in a keep-alive session, for
example, it is convenient for the lowest layer (gzip) to close the
next layer (chunked) but not the socket.

Regards