rproxy development has been moving along. There's a moderately-stable
beta out there, but things have been changing consideraly behind the
scenes.
The main challenge for this year has been to take the existing proxy
and rsync code, and turn it into something that can be reused in
programs like Apache, Squid, and Mozilla. These are all quite
different on the inside, and I've had a few false starts at designing
a library interface that would work with all of them, and keep the
implementation reasonably simple.
The current interface intentionally looks a lot like zlib: it performs
encoding/decoding/signature-generation operations between
caller-supplied memory buffers. These operations are all kind of
"non-blocking": they'll process as much data as they can until running
out of either input data or output space or both, and then return to
the caller. When the calling application has more input or output
space, they call back in again. So, I hope this will work with
whatever IO system the application uses: blocking, nonblocking, or
threaded. So there are no callbacks, and the library will accept
whatever it's given. If you want, you can do input and output one
byte at a time.
There is also a higher-level stdio-like interface. For example, using
this you can open a patch file (passing in the file to be patched) and
read out the results of the patch.
I hope this can eventually replace the coding functions in rsync,
although at the moment Rusty is going ahead on rsync 3.0 with a much
simpler and less flexible library.
Any comments on how this will work in your apps would be very welcome.
--
Martin Pool http://linuxcare.com.au/rproxy/
rproxy accelerates HTTP by dynamic caching and differential update
