RJT>> What annoys me more than anything else is the limitations
 RJT>> built into some software that isn't exactly related to size,
 RJT>> but to line count!

 ml>> and its even more annoying if one stops and really
 ml>> looks that the specs for fidonet messages... namely the
 ml>> line that says that message bodies are unbounded ie:
 ml>> unlimited in size... the limits and such that are in
 ml>> place came from "lazy coders" who didn't want to take
 ml>> the time to figure out how to work around handling
 ml>> stuff larger than their available buffer(s)... reminds
 ml>> me of that old bill gates saying about 640K of memory...

 BJ> Mark:

 BJ> How long have you been around fidonet?

i took part in the vote process that put Policy4 in place... is that long
enough? >

 BJ> Yes, the specs don't specify a limit.  There was common
 BJ> agreement that *unlimited* was not realistic back when the
 BJ> original specs were designed.  Running fidonet on two 360Kb
 BJ> floppy disks with 176Kb of memory in the system didn't leave a
 BJ> lot of room.....  Ok, so I was later able to add 10 Mb, 20Mb
 BJ> and later 40Mb hard disk drive to the system and later 756Kb
 BJ> of memory....    Modern systems could handle significantly
 BJ> larger messages than what we could back then -- if software
 BJ> kept up.  No, maximus did not run on that original, limited
 BJ> hardware.....   But the original fido / fidonet did run on
 BJ> that original hardware.

yes, i know... i had some fido stuff running on old zenith systems... if it
wasn't for finding the right fossil drivers, i'd have never gotten that
stuff operational >

 BJ> From memory, squish can currently
 BJ> (when properly configured) handle up to 256Kb or 512Kb message
 BJ> size.  Based on ~5Kb per regular type written page, that's
 BJ> over 50 type written pages for a fidonet mesage, and these are
 BJ> messages, not file attachments, html, etc.  Fidonet messages
 BJ> are (mostly) just ASCII text....  I don't see the need to
 BJ> write a short novel for a fidonet message -- net mail or echo
 BJ> mail....  Not what this media was intended for....

if that's the case, then why were the message limits designed with no
limitation on the message size? surely someone was looking to the future...

 BJ> Even standard (unix) send mail had message size limits,
 BJ> typically set to 5Mb for the maximus e-mail message size....
 BJ> So, I don't buy the need for unlimited message size.  There
 BJ> are other protocols for sending files around.  This protocol
 BJ> was designed for readable text based messages.

i didn't say there was a need however, every agrees that if coders had paid
attention to the specs, there wouldn't be any of these arbitrary limits
that people run into...

FWIW: i have software that i wrote that has no problem posting the raw
ascii nodelist as one message... yes, even the largest nodelist that
fidonet had... that was what? 2+meg in size? and i remember another coder
announcing that he had written the first mail tossing software that
properly handled messages of unlimited size by spooling anything larger
than the memory buffer to disk... that's the proper way, really... of
course, no one stopped to think unlimited meant that hardware limitations
were the limit... with today's stuff, i see no reason why we couldn't
include pictures and other binary data in our messages... why should we
have to resort to internet email for that when our stuff can handle it if
it is properly written... note that i'm only talking about getting the
picture into the message, transferring it to the remote and letting them
figure out how to get it out for display purposes... uu or mime encoding is
one easy method...

besides, internet email didn't start out designed to carry this
information, either... it has grown as needed to... why can fidonet's stuff
do the same??? at least, we can learn from the mistakes that the internet
stuff has run into...

)\/(Ark