Subj : Another filearea question
To : Mark Lewis
From : Mvan Le
Date : Mon Jun 11 2007 06:24 am
ml> you obviously don't have a clue what information is
ml> contained within the exitinfo.bbs file, then... for one
ml> thing, tell me if door.sys can carry the info on what
ml> message areas a user has selected to join... never
ml> mind, as you can't tell me that... truth be known,
Heh. The keyword is "can" - and surprise door.sys can.
ml> exitinfo.bbs carries all bbs config information as it
ml> relates to the currently logged on user...
So why should dorinfo1.def carry any more details. It satisfied the requirement
of whomever invented it.
If people deviate from the specification and adopt different methods for using
dorinfo1.def that's their perogative, which doesn't change the fact that the
number in the dorinfo1.def dropfile was never meant to designate a node number.
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.
ml> duh? i think i've been doing this a few more years than
ml> you have, Mvan... at least as long as you are years
ml> old, thankyouverymuch...
Oooo wow I'm scared.
>> 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.
ml> it doesn't read that way... apologies if i misread your
ml> mind as you didn't say that in that manner...
Does "65535" LOOK like an arbitrary number to you ?
>> 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.
ml> we're not talking about just you... there are others in
ml> the world doing this stuff ;)
And they voluntarily work within any existing or implied constraints. But
ultimately it's not my problem.
Software limitations eg. integer, character limits etc. may be the result of
conscious decisions to preserve valuable runtime resources. Y2k compatibility
is an example.
Even today's web forms, or even databases ask the admins/programmers to define
maximum line length and tablespace usage limits.
These are not "arbitrary" decisions due to lack of foresight as you love to
accuse, but are based on what is warranted and/or required at the time of
implementation, and which may often remain up to the descretion of those
implementors.
H> Firstly, I definitely would seriously reconsider using any
H> mail readers limited to a crappy 200 line message.
ml> then i guess you don't use bluewave or any other
ml> similar offline mail readers...
I use Bluewave OLR. I've never had a problem with it. Heh.
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.
ml> that's all well and good... too bad the split proposal
ml> that squish and others follow is directed at the wrong
ml> side of the "too large a message" problem :
It's a problem because of your point of view.
--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)
