
\begin{DoxyItemize}
\item We have a few functions to do with reading a netint, stashing it somewhere, then moving into a different state. Is it worth writing generic functions for that, or would it be too confusing?
\item Optimisations and code cleanups;

\mbox{\hyperlink{scoop_8c}{scoop.\+c}}\+: Scoop needs major refactor. Perhaps the API needs tweaking?

rsync.\+h\+: \mbox{\hyperlink{structrs__buffers__s}{rs\+\_\+buffers\+\_\+s}} and rs\+\_\+buffers\+\_\+t should be one typedef?

\mbox{\hyperlink{mdfour_8c_source}{mdfour.\+c}}\+: This code has a different API to the RSA code in libmd and is coupled with librsync in unhealthy ways (trace?). Recommend changing to RSA API?
\item Just how useful is rs\+\_\+job\+\_\+drive anyway?
\item Don\textquotesingle{}t use the rs\+\_\+buffers\+\_\+t structure.

There\textquotesingle{}s something confusing about the existence of this structure. In part it may be the name. I think people expect that it will be something that behaves like a FILE$\ast$ or C++ stream, and it really does not. Also, the structure does not behave as an object\+: it\textquotesingle{}s really just a shorthand for passing values in to the encoding routines, and so does not have a lot of identity of its own.

An alternative might be

result = rs\+\_\+job\+\_\+iter(job,                          in\+\_\+buf, \&in\+\_\+len, in\+\_\+is\+\_\+ending,                          out\+\_\+buf, \&out\+\_\+len);

where we update the length parameters on return to show how much we really consumed.

One technicality here will be to restructure the code so that the input buffers are passed down to the scoop/tube functions that need them, which are relatively deeply embedded. I guess we could just stick them into the job structure, which is becoming a kind of catch-\/all \char`\"{}environment\char`\"{} for poor C programmers.
\item Meta-\/programming
\begin{DoxyItemize}
\item Plot lengths of each function
\item Some kind of statistics on delta each day
\end{DoxyItemize}
\item Encoding format
\begin{DoxyItemize}
\item Include a version in the signature and difference fields
\item Remember to update them if we ever ship a buggy version (nah!) so that other parties can know not to trust the encoded data.
\end{DoxyItemize}
\item abstract encoding

In fact, we can vary on several different variables\+:
\begin{DoxyItemize}
\item what signature format are we using
\item what command protocol are we using
\item what search algorithm are we using?
\item what implementation version are we?
\end{DoxyItemize}

Some are more likely to change than others. We need a chart showing which source files depend on which variable.
\item Encoding algorithm
\begin{DoxyItemize}
\item Self-\/referential copy commands

Suppose we have a file with repeating blocks. The gdiff format allows for COPY commands to extend into the {\itshape output} file so that they can easily point this out. By doing this, they get compression as well as differencing.

It\textquotesingle{}d be pretty simple to implement this, I think\+: as we produce output, we\textquotesingle{}d also generate checksums (using the search block size), and add them to the sum set. Then matches will fall out automatically, although we might have to specially allow for short blocks.

However, I don\textquotesingle{}t see many files which have repeated 1kB chunks, so I don\textquotesingle{}t know if it would be worthwhile.
\end{DoxyItemize}
\item Support compression of the difference stream. Does this belong here, or should it be in the client and librsync just have an interface that lets it cleanly plug in?

I think if we\textquotesingle{}re going to just do plain gzip, rather than rsync-\/gzip, then it might as well be external.

rsync-\/gzip\+: preload with the omitted text so as to get better compression. Abo thinks this gets significantly better compression. On the other hand we have to important and maintain our own zlib fork, at least until we can persuade the upstream to take the necessary patch. Can that be done?

abo says \begin{DoxyVerb} It does get better compression, but at a price. I actually
 think that getting the code to a point where a feature like
 this can be easily added or removed is more important than the
 feature itself. Having generic pre and post processing layers
 for hit/miss data would be useful. I would not like to see it
 added at all if it tangled and complicated the code.

 It also doesn't require a modified zlib... pysync uses the
 standard zlib to do it by compressing the data, then throwing
 it away. I don't know how much benefit the rsync modifications
 to zlib actually are, but if I was implementing it I would
 stick to a stock zlib until it proved significantly better to
 go with the fork.
\end{DoxyVerb}

\item Licensing

Will the GNU Lesser GPL work? Specifically, will it be a problem in distributing this with Mozilla or Apache?
\item Testing
\begin{DoxyItemize}
\item Just more testing in general.
\item Test broken pipes and that IO errors are handled properly.
\item Test files \texorpdfstring{$>$}{>}2GB, \texorpdfstring{$>$}{>}4GB. Presumably these must be done in streams so that the disk requirements to run the test suite are not too ridiculous. I wonder if it will take too long to run these tests? Probably, but perhaps we can afford to run just one carefully-\/chosen test.
\item Fuzz instruction streams. \href{https://code.google.com/p/american-fuzzy-lop/}{\texttt{ https\+://code.\+google.\+com/p/american-\/fuzzy-\/lop/}}?
\item Generate random data; do random mutations.
\item Tests should fail if they can\textquotesingle{}t find their inputs, or have zero inputs\+: at present they tend to succeed by default.
\end{DoxyItemize}
\item Security audit
\begin{DoxyItemize}
\item If this code was to read differences or sums from random machines on the network, then it\textquotesingle{}s a security boundary. Make sure that corrupt input data can\textquotesingle{}t make the program crash or misbehave. 
\end{DoxyItemize}
\end{DoxyItemize}