Text 676, 93 rader
Skriven 2007-06-11 06:24:46 av Mvan Le (1:343/41.0)
    Kommentar till text 670 av Mark Lewis (1:3634/12)
Ärende: Another filearea question
=================================
 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)