-*- indented-text -*-

Use the map_ptr interface from rsync to do IO, so that we don't have
to worry so much about buffering the input.

However, first make sure that this will interface cleanly with the
abstract IO layers in Apache, Squid, Mozilla etc.

map_ptr also knows how to seek in a file and will do that on demand.
This obviously won't work on a stream, but then it should never be
called if we're using the stream properly, so it's probably harmless
to leave it in there.  Is that true?  Can it ever seek forward and
discard stuff?  

map_ptr also expects to know the length of the file when it starts,
which in general we won't know.  Rather, we need our input routine to
tell us when it's neared the end of the file.

So, we have to either extend map_ptr to do this, or put some of its
intelligence into inbuf.c.  inbuf is already mostly there, but it
could be better.

There's already a test case for map_ptr, but if we're going to use
inbuf then we should write a test case for it as well.  The
requirement is basically that you can ask it to map any sequence of
forward-moving windows, and it will always work.  ``Forward-moving''
means that the base of the window never moves backwards, so we can
always discard everything before it.  I think we'll want to require
inbuf.c to cope with windows that might shrink or grow.  We'll never
want to skip over data, so I guess it ought to detect and trap that.

It makes a big difference whether we're at the end of the stream or
not, because the checksums will be different.  Therefore end of file
and short blocks can only happen once, and we need inbuf to
unequivocally tell us when it's happening.