>> MvanL> Which is all pointless unless the door is
>> MvanL> programmed to read the most recent created *.def
>> MvanL> file or accept a node number as a command line
>> MvanL> option.
>> haha... good thing you're not a real programmer, then O:)
H> RA should drop support for exitinfo and strictly adhere to
H> door.sys standards then, because their programmers couldn't
H> fathom the limiting issues with their chosen implementation.
you obviously don't have a clue what information is contained within the
exitinfo.bbs file, then... for one thing, tell me if door.sys can carry the
info on what message areas a user has selected to join... never mind, as you
can't tell me that... truth be known, exitinfo.bbs carries all bbs config
information as it relates to the currently logged on user...
>> 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 ;)
H> What's wrong with passing the node number as an option to
H> the door ? hence rendering node number dropfile naming
H> conventions irrelevant. Believe it or not it works for
H> many doors out there.
duh? i think i've been doing this a few more years than you have, Mvan... at
least as long as you are years old, thankyouverymuch...
>> MvanL> A "/node=65535" sounds pretty limitless to me.
>> furrfu, damn good thing you're not a real programmer ;) it
>> is arbitrary limit like that that have caused all kinds of
>> problems over the years...
H> It's not an arbitrary limit. It's an example command line
H> option.
it doesn't read that way... apologies if i misread your mind as you didn't say
that in that manner...
>> 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 ;)
H> Which are all issues for the relevant applications and users
H> of those applications, and are non existent problems for me.
we're not talking about just you... there are others in the world doing this
stuff ;)
H> Firstly, I definitely would seriously reconsider using any
H> mail readers limited to a crappy 200 line message.
then i guess you don't use bluewave or any other similar offline mail
readers...
H> Secondly because Squish can be configured to split large
H> packet sizes I have no problem sending or receiving messages
H> for any practical purpose.
that's all well and good... too bad the split proposal that squish and others
follow is directed at the wrong side of the "too large a message" problem :(
