Subj : Another filearea question
To : Mvan Le
From : mark lewis
Date : Sat Jun 09 2007 05:56 pm
ml>> i've seen implementation that use hex and as such can
ml>> support up to 16 nodes... i've also seen
ml>> implementations that support base36 which is also
ml>> limiting on a large multinode system... then, there're
ml>> those that start dropping letters to make room for numbers...
MvanL> Which is all pointless unless the door is programmed to read
MvanL> the most recent created *.def file or accept a node number as
MvanL> a command line option.
haha... good thing you're not a real programmer, then O:)
what's wrong with passing the dropfile name on the command line and letting the
door parse that filename to determine the node number? believe it or not, it
works for many doors out there ;)
MvanL> A "/node=65535" sounds pretty limitless to me.
furrfu, damn good thing you're not a real programmer ;) it is arbitrary limits
like that that have caused all kinds of problems over the years...
for instance...
1. some popular offline mail readers have a 200 =line= limit...
2. some FTN mail tossers can't process FTN messages larger than
16K... fewer can handle 32K... what's the problem? the specs
state that the message body of a packed message is
unbounded... that means that you read until you hit the next
null character not just read 16K... that's laziness, amoung
other things ;)
3. [damn, i had another well known one and lost it :( ]
