Subj : proposed new nodelist
To   : mark lewis
From : Jasen Betts
Date : Fri Jul 26 2002 09:58 am

Hi mark.

24-Jul-02 16:57:34, mark lewis wrote to Jasen Betts


 ml>>> nope... the MNP flag means one thing... V42 means another... in
 ml>>> fact, as i recall, V42 was a speed and V42B is/was error
 ml>>> correction

 JB>> I think V42 is eror recovery and V42B is compression as well as
 JB>> error recovery.

 ml> nope... its only one or the other... that was one of the first
 ml> confusing flags i've run into..

AH, I was describing CCITT protocols, you were describibing flags with
similar names. ir makes sense that old software wouldn't know that V42b
implies V42. (according to CCITT) so the fido docs say you should indicate
both if if you do V42b.

 ml> i dunno... i'm visualizing the flow in pascal (actually)... i'm
 ml> just seeing the first row filled and then the reading of the next
 ml> line and parsing it for each field just not being that hard... and
 ml> then to overlay the changed fields on the old, no biggie... kinda
 ml> like using a buffer to store the data in and then using different
 ml> structures that are overlaid right on top of that buffer... gosh,
 ml> what is/was the term used for that

 ml> [time passes]

 ml>  pkthead1 absolute bheader;

You can't just "absolute" them over each other  because then reading one
would erase the next...

 ml> understand but also hear others "screaming" about the "bulkiness"
 ml> and duplication of the data... that has always been a bitch...
 ml> "the nodelist is too large. why can't we cut it down in physical
 ml> size?

size doesn't really worry me... sure whn it was 3 megs it took about 20% of
my hard space to edit it (for a friend with an amiga who didn't have enough
ram - neither did I but wordstar doesn't need big ram to edit a big file)

 ml> true but it'll still build out to be a line once you get to the
 ml> line terminator..

depends how you code the reading...

 JB>> 255?, that short? why?

 ml> ummm, turbo pascal is still used by many newbie (and long time)
 ml> developers... not to mention that there are even bbs message base
 ml> formats built on that particular limit... the HMB MSGTXT.BBS file
 ml> is one such... nothing but rows of strings..

so pascal programmer will have to treat a long-line file as lines
containing fileds rather than just a bunch of strings,

as soon as they decide to they can ignore a line they can do READLN; and
they'll be at the next line.

they'll have to use a "readfield" procedure for getting the data from the
file into strings but that shouldn't be a big hassle, they only need to
write it once, and can use it for all fields.  if done using the ttextrec
object (actually not "ttextrec", but that's the naem in the online help) it
needn't mean yhe inefficinet  practice of repeatedly reading a single
character searching for a comma.)

 JB>> yeah 255 is pretty cramped, way too short for my proposal.

 JB>> Probably fewer than 10 rulesets would suffice for 99% of fidonet

 ml> agreed... and my thoughts are that they'd likely be coded in the
 ml> program and this reside in the .EXE (to use dos think for a
 ml> moment)..

could be, but that makes upgrades hard on the bandwidth unless external
rulesets can be used too.

 -=> Bye <=-

---
 * Origin: He who Laughs, Lasts. (3:640/531.42)

.