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.
