TIP: Click on subject to list as thread! ANSI
echo: meadow
to: MEL PHEASANT
from: TREV ROYDHOUSE
date: 1997-03-22 00:00:00
subject: Re: Max v2.0x - Opus 1.7x

 > You know my thoughts on *.msg. Simple, works well, and 
 > on a properly partitioned disk, doesn't take *too* 
 > much space. A lot of utils work with it, and you can 
 > manipulate them individually. Plus, if your software 
 > goes t*ts up, you don't lose the whole base.  
I gather from the above that you are assuming a single message database. I 
don't believe that was ever intended, so you certainly would not lose all 
your messages.  
 > I dunno why people want a message database these days.  
 > Disk space has grown a lot faster than fido, and for 
 > that matter disks have grown faster than the nodelist 
 > as well (just thought I'd throw that in, too).  
If you're talking DOS, and that is where most of the utilities for *.msg 
files exist, then disk space per se could be deemed irrelevant, subject to 
the 2gb partition limit.  I'm not sure though that people want to waste 32k 
per message, even with disk space hog heaven.  
Actual disk space was never the main reason for developing a message 
database. The flaws in the DOS FAT file system were.  It remains true today 
that if you place a couple of hundred files into a single DOS directory, the 
system slows to a crawl despite the fact that you may be using the latest 
bleeding edge SCSI-III disk drive and SCSI host adapter or mode 4 EIDE drive. 
 
Yes, I know, if you throw a large enough disk cache (RAM) at that problem, 
you can effectively double the number of messages before the system slowdown 
becomes too painful.  Personally, I use, and still use, an 8mb disk cache to 
overcome the problem. But note that you also have to defragment your drive 
frequently for even this bandaid solution, such as it is, to work.  
The message database was the technical solution which was *demanded* by Opus 
sysops. Doug didn't just start working on it because he had too much spare 
time on his hands.  
 > Seems pretty clear to me. Sigh.  
I trust that the above explanation has made it even clearer.  
TREV.
--- QM v1.30 
---------------
* Origin: Sentry -- Sydney, New South Wales, Australia (3:711/401.0)

SOURCE: echomail via exec-pc

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