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...

)\/(ark