Subj : proposed new nodelist
To : mark lewis
From : Jasen Betts
Date : Fri Jul 26 2002 10: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)
* Origin: Baddog BBS (1:218/903)
