[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Chunked Encoding
Re: Chunked Encoding
Tue, 8 May 2012 11:26:56 +0800
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.