On 6 May 2012 12:52, Ian Price <[email protected]> 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
