Notes for hacking on /rproxy/
Copyright (C) 2000 by Martin Pool

> documentation

The documentation is mostly in Linuxdoc SGML.  You'll need the
sgmltools package to rebuild it, and LaTeX to generate pretty output.

The flowchart is done using the `Sketch' drawing tool, and then
converted to PS, EPS, and PNG.

This is not handled by automake at the moment.

> structure

Hey, how simple is this?  rproxy is not and will not be multithreaded
in this incarnation, so it's essentially straight-line code: we read a
request, work out how to handle it, and send a response.  There need
not be any very tricky OO code, it just has to be clean.

> dependencies

rproxy uses GNU libc extensions because it doesn't seem useful to
recreate them in our code at the moment.  Send patches if you want to
build on nonfree systems.

> error handling

Return a negative number on error and set errno.

> memory management

 > talloc

It might be good to switch to tridge-alloc, because there are very
natural pools of memory use for each request.

> inline signatures

We need a really efficient way to encode this.  Mm, in some ways it
seems silly to send across the network data that could reasonably be
generated on the client on demand.  Software patents are such a
terrible brake on innovation.

For the time being we will just send the signature at the end and let
the client cope.  We can worry about interrupted transfers later --
let's do it one step at a time!

 > callbacks per packet

This means that we intermingle the signature packets with the
difference packets.  This is fine, but it's going to somewhat disrupt
librsync, which would like to see the two operations as entirely
separate.  Well, that's OK: we can probably be more efficient if we
put them in together anyhow.

 > combined encode/sign functions

This looks like the way to go: put the code into the library where it
belongs.

> buffering issues

We want to process input in the largest chunks possible, so that
encoding can be efficient.  However, we also don't want to introduce
too much slop between the client and the receiver.

> debugging

 > ccmalloc

If you configure with --enable-ccmalloc you get the ultracool `ccmalloc'
memory-debugging library, which is just the thing for detecting memory
leaks and similar ailments. 

> security

Try

  http://www.linuxpowered.com/html/linux_links/sec_doc/secure_programming_checklist




Local Variables:
mode: outline
outline-regexp: " *>"
End: