TIP: Click on subject to list as thread! ANSI
echo: muffin
to: Mike Tripp
from: mark lewis
date: 2003-06-13 21:04:06
subject: Squish progress

ml>> the ^ASPLIT proposal... IMO, it was implemented on the wrong
 ml>> side of the problem... systems that cannot handle large
 ml>> messages should split those messages for tossing into their
 ml>> message areas... anyone feeding from that system should get
 ml>> the original, unsplit message and split it themselves if
 ml>> needed... the same goes for those QWK doors... they should
 ml>> split the messages down into what the user's reader can
 ml>> handle...

 MT> The only problem with that logic is that =every= system
 MT> cannot handle large messages, if large is defined as
 MT> unlimited.

that's why its up to /them/ to split... they are restricted only by their
hardware limitations...

 MT> What are the minimum hardware and software
 MT> requirements to receive "infinitely large" messages?

hahaha... good one! >

 ml>> and i'll mention, once again, about the specs for packed
 ml>> messages stating that the message body is unbounded... ie:
 ml>> no size limit...

 MT> And the very next thing that same spec defines is the
 MT> character required to denote the boundary of the "unbounded"
 MT> portion... :)

right... the size is unbounded... however, this character denotes the end
of the message body and what follows are the ending control paragraphs...

 MT> Fortunately for Fido, most programmers willingly condensed
 MT> "unlimited specified" to "unspecified"...and so we got
 MT> "programmer's choice"/pot luck/de facto.  Since my OS/2 box
 MT> can theoretically scan out a message larger than my DOS box
 MT> can create a disk partition to store...I don't see where
 MT> Scott's code needs a lot of "fixing" in this regard.  Tossers
 MT> don't mean much if you can't pass their output around freely.
 MT> ;)

i wasn't necessarily speaking about fixing scott's code in this regard...
t'was more of just a FYI that many don't even know about... if those in
fido's history has really known this, there wouldn't have been software
with line (!) limits and there would have been more software that was able
to handle larger messages than 16k, 32k and 64k...

)\/(ark

* Origin: (1:3634/12)
SEEN-BY: 633/267 270
@PATH: 3634/12 106/2000 633/267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.