librsync  2.3.2
Todo List
File buf.c

Perhaps expose a routine for shuffling the buffers.

Perhaps be more efficient by filling the buffer on every call even if not yet completely empty. Check that it's really our buffer, and shuffle remaining data down to the front.

File emit.c
Pluggable encoding formats: gdiff-style, rsync 24, ed (text), Delta HTTP.
File mdfour.c
Perhaps use the MD4 routine from OpenSSL if it's installed. It's probably not worth the trouble.
File msg.c
(Suggestion by tridge) Add a function which outputs a complete text description of a job, including only the fields relevant to the current encoding function.
File rdiff.c

If built with debug support and we have mcheck, then turn it on. (Optionally?)

Add an option for delta to check whether the files are identical.

popt doesn't handle single dashes very well at the moment: we'd like to use them as arguments to indicate stdin/stdout, but it turns them into options. I sent a patch to the popt maintainers; hopefully it will be fixed in the future.

Add a -z option to gzip/gunzip patches. This would be somewhat useful, but more importantly a good test of the streaming API. Also add -I for bzip2.

Global rs_delta_begin (rs_signature_t *)
Add a version of this that takes a rs_magic_number controlling the delta format.
Global rs_mdfour64 (rs_mdfour_t *m, const void *p)
Recode to be fast, and to use system integer types. Perhaps if we can find an mdfour implementation already on the system (e.g. in OpenSSL) then we should use it instead of our own?
Global rs_patch_begin (rs_copy_cb *copy_cb, void *copy_arg)

Implement COPY commands.

As output is produced, accumulate the MD4 checksum of the output. Then if we find a CHECKSUM command we can check it's contents against the output.

Global rs_trace_to (rs_trace_fn_t *new_impl)
Do we really need such fine-grained control, or just yes/no tracing?
Global rs_tube_copy (rs_job_t *job, size_t len)
Try to do the copy immediately, and return a result. Then, people can try to continue if possible. Is this really required? Callers can just go out and back in again after flushing the tube.
File scoop.c
We probably know a maximum amount of data that can be scooped up, so we could just avoid dynamic allocation. However that can't be fixed at compile time, because when generating a delta it needs to be large enough to hold one full block. Perhaps we can set it up when the job is allocated? It would be kind of nice to not do any memory allocation after startup, as bzlib does this.
File stats.c
Other things to show in statistics: number of input and output bytes, number of times we blocked waiting for input or output, number of blocks.
File trace.c
Have a bit set in the log level that says not to include the function name.
File trace.h
A function like perror that includes strerror output. Apache does this by adding flags as well as the severity level which say whether such information should be included.
File tube.c

As an optimization, write it directly to the stream if possible. But for simplicity don't do that yet.

I think our current copy code will lock up if the application only ever calls us with either input or output buffers, and not both. So I guess in that case we might need to copy into some temporary buffer space, and then back out again later.