Subj : Another filearea question To : mark lewis From : Hostile Date : Sun Jun 10 2007 02:55 am > ml>> ie: dorinfo1.def dorinf22.def dorin134.def > MvanL> Which is all pointless unless the door is programmed to read the mos > MvanL> recent created *.def file or accept a node number as a command > MvanL> line option. > haha... good thing you're not a real programmer, then O:) RA should drop support for exitinfo and strictly adhere to door.sys standards then, because their programmers couldn't fathom the limiting issues with their chosen implementation. > what's wrong with passing the dropfile name on the command line and letting > door parse that filename to determine the node number? believe it or not, it > works for many doors out there ;) What's wrong with passing the node number as an option to the door ? hence rendering node number dropfile naming conventions irrelevant. 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 > limi > like that that have caused all kinds of problems over the years... It's not an arbitrary limit. It's an example command line option. > 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 ;) Which are all issues for the relevant applications and users of those applications, and are non existent problems for me. Firstly, I definitely would seriously reconsider using any mail readers limited to a crappy 200 line message. Secondly because Squish can be configured to split large packet sizes I have no problem sending or receiving messages for any practical purpose. .