berrytech at bigfoot.com
Sun Apr 5 16:49:13 EDT 1998
>1) Make the buff-in file be FIFO instead of FILO.
Agreed. This shouldn't be difficult to do, and would prevent blocks getting
"too old." It would also make a number of people on the list happier. =)
>2) Remove the size limitation on buff-* files.
I understand there currently is no limit, so we're all good here.
>3) Create a utility to merge buff-* files.
Still too complicated! Instead, here's my big future plan for the clients. The
client is a shell that can communicate and do units of work. Each contest gets
its own directory. There are plug-in files for each contest which tell it how
to do a unit of work and how to read any required files (buffers,
checkpoints). The specific contest plug-in and its required data are stored in
that contest's directory. (And surely the keyservers servers could have
contest plug-ins as well.)
Further, there could be "in" and "out" directories in each contest's folder as
well. The file with the oldest date is read first, again to prevent
stagnation. So, very simply, you can put as many in-buffer files into the "in"
directory and the client will work correctly. No merging utility necessary. No
renaming files necessary. (In-buffer files could be named absolutely anything,
Multiple out-buffers could be created as well. Suppose your e-mail system has
a limit on the size of attachments; you could specify that out-buffers must be
under 500k, or whatever, and that a new out-buffer be created at that time.
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5