No subject

> #define MSG_HELLO			1

> #define MSG_QUIT			3
> #define MSG_NO_QUIT_YET 		4 // XXX needed??
> #define MSG_ABORT			5

> #define MSG_NOTE_DIRNAME		6
> #define MSG_NOTE_FILENAME		7
> #define MSG_DEC_REFCNT			8

These might work better as an enum, so that gdb can show symbolic
values.

> typedef struct {
>     char *names[MAX_ID_LIST_LEN];
>     long nums[MAX_ID_LIST_LEN];
>     int count;
> } ID;

Linus has a rule about not using typedefs for structures, because it's
good to be clear about whether something is a structure or whatever.
I'm inclined to agree.  So I would refer to that thing "struct rz_id"
or something.

Being 64-bit clean probably implies declaring rz_time_t, rz_uid_t and
so on, and using that rather than the native types, which will be
pretty random.

> This also reminds me that I hadn't responded to jw's question about why
> I thought his pipelined approach was more conducive to a batch protocol
> than an interactive protocol.  To make the pipelined protocol as
> efficient as rsync will require the complexity of his backchannel
> implementation, which I think will be harder to get right than a
> single-process message-oriented protocol.  If every stage is a separate
> process, it seems less clear how to implement something like an
> interactive "mkdir" or a "delete" command. (What process handles this?
> How do we signal that process?  Do we need yet another socket path for a
> control stream in some circumstances?)  It also seems to me that the
> extra processes/threads and socket-channels will make a less portable
> interactive app than a single select-using interactive app.

I wasn't clear if the types were meant to be real pipes (with
socketpair() or pipe()), or just conceptual flows of information.  I
agree that the first one is interesting but probably not a good idea.

The second one is probably a good way to visualize things, and
something along those lines ought to be in the programmer's
documentation.

(By the way, my mail client was temporarily confused and sent mail as
"mbp at toey.home", which is obviously wrong; please use samba or
sourcefrog.)

-- 
Martin