[RC5] Really useful feature request
john.graves at nashville.com
Fri Apr 3 19:36:38 EST 1998
>Hmm... if you can do this, then why not just point the client to this
>directory in the first place?
With my machines behind the firewall at work, I like to make sure that they
have enough blocks for the weekend. Last weekend for example, I had to
rename the current buff-in.rc5 and replace it with a full 1000 block file to
insure that they would have enough blocks while I was away since I only had
about 120 blocks left in that file. I do understand that they will work on
random blocks if they run out. While that isn't a problem currently with so
much keyspace territory untouched, later it may become important. It would
be nice to be able to specify a backup block directory or perhaps even
better, just be able to have the client look for buff-in2.rc5 then
buff-in3.rc5 and so on.
>That seems like a good idea... but are there really all that many machines
>that can email out where the client can't flush via the normal methods?
>shouldn't be an incredable amount of work -- the STMP code is already there
>for the log mailings. We would need to implement base64 encoding.)
My work machines are in that situation. E-mail is no problem, but I cannot
fetch/flush to the server directly even with a numeric address. Of course I
have no idea how many more there are out there in a similar situation.
Obviously I can get by without these enhancements, but as I said, it would
make things a bit easier for me.
John A. Graves -- Amateur Telescope Maker, Founder & Moderator - Fidonet ATM
john.graves at nashville.com *or* starwanderer at geocities.com
Visit my WWW page or submit articles to the Electronic ATM Journal at:
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5