Subj : proposed new nodelist
To : Jasen Betts
From : mark lewis
Date : Fri Aug 16 2002 02:04 pm
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;
JB> You can't just "absolute" them over each other because then
JB> reading one would erase the next...
i understand that... its the concept... that code snip is from one of my PKT
analyzers... it hops between the different ones searching for the one that has
the least amount of "garbage" in the fields so as to determine what PKT type
(2, 2.0, 2+) is being used...
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?
JB> size doesn't really worry me... sure whn it was 3 megs it took
JB> about 20% of my hard space to edit it (for a friend with an
JB> amiga who didn't have enough ram - neither did I but wordstar
JB> doesn't need big ram to edit a big file)
right but it does (still) bother many... this network is dropping folk all the
time... the ones who are left are many of our older members... there will come
a time when the average age of a fidonet sysop is >50... i suspect that its
close to that now if not already more...
ml>> true but it'll still build out to be a line once you get to
ml>> the line terminator..
JB> depends how you code the reading...
EOL is EOL is EOL, no matter how you code it...
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..
JB> so pascal programmer will have to treat a long-line file
JB> as lines containing fileds rather than just a bunch of
JB> strings,
can't! can't read lines/strings longer then 255 characters by default... can
only do so with 'outside' code, not stuff already existing in all languages...
JB> as soon as they decide to they can ignore a line they can do
JB> READLN; and they'll be at the next line.
won't work on lines greater then 255 characters... definitely not for a new
coder with the free TP 5.5 from borland's site...
JB> they'll have to use a "readfield" procedure for getting the
JB> data from the file into strings but that shouldn't be a big
JB> hassle, they only need to write it once, and can use it for
JB> all fields. if done using the ttextrec object (actually not
JB> "ttextrec", but that's the naem in the online help) it
JB> needn't mean yhe inefficinet practice of repeatedly reading
JB> a single character searching for a comma.)
ahhh... i see (now) that you are also thinking in OOP style coding... i haven't
been... i'm a procedural type of guy...
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)..
JB> could be, but that makes upgrades hard on the bandwidth unless
JB> external rulesets can be used too.
what bandwidth? we're talking about a small tool that should be less than
50k... allowing for external rulesets also opens the door for someone to screw
something up...
