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...

 ml>>   ie: dorinfo1.def
 ml>>       dorinf22.def
 ml>>       dorin134.def

 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 :( ]

)\/(ark