Subj : SMB style msg areas?
To   : David Gonzalez
From : Steve Quarrella
Date : Thu Feb 15 2001 05:56 am

 DG> SMB is the standard that Synchronet BBS uses if you wanna learn
 DG> more about it just visist http://www.syncghro.net/docs

Aha...that could be a problem.  So Rob doesn't support *.MSG, Squish, JAM, or 
HMB, or is it that SMB is preferable in some way if you're running a Synchronet 
system?

 DG> Nope is no squish, and about that would you tell me what's better
 DG> to use Squish *MSG, Hudson or JAM?, i'm suing JAM and i've always

That's a tough question to answer.  For my needs, I use HMB for smaller areas, 
because it's fast and easy to maintain, while its down side is that if I lose 
the whole HMB, all those message areas are gone.  HMB doesn't keep track of 
when the message arrives on your system, versus when it was written.  So, if 
someone writes a message a month ago and it just gets to me today, it's going 
to be purged tonight in my message base packing event, because I delete 
messages that have been here for three weeks.  With JAM, I don't have that 
problem, and I have greater flexibility with those bigger areas.  I don't use 
Squish, because my software doesn't support it, but it's just fine, too, in 
that it and JAM are essentially miniature databases for each area.  *.MSG is 
the least preferable, as it's one file per message, and that can add up to a 
lot of wasted cluster space and a lot of overhead for your utilities.  In fact, 
I was working with someone here in Region 19 who had some -huge- *.MSG bases, 
and things got to a point where her echomail processor just wouldn't export 
anymore, for some reason.  Once she moved those *.MSGs to another folder and 
started fresh, she could toss and scan as she expected.

All told, use what works best for your needs.  A lot of folks would sneer at my 
using an HMB, but in the long run, it works out for me (be aware that it has a 
size limitation of 16 MB, and only 200 message areas or so).

---
 * Origin: Where'd you get the gun, John? (1:393/9005)

.