| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| 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™.