TIP: Click on subject to list as thread! ANSI
echo: allfix_help
to: mark lewis
from: Dan Egli
date: 2003-03-23 23:08:54
subject: help?

Hello mark.

23 Mar 03 20:16, you wrote to me:

 DE>> Glad to know someone is still supporting the good product. Now
 DE>> if I could only find a decent Echomail tosser that was still
 DE>> being developed :> FastEcho is good, but it's not supported
 DE>> anymore,

 ml> i disagree that FE is not supported anymore... i'm still a member of
 ml> the beta team and others and myself still provide support and answer
 ml> questions posted in the support echo...

I meant to say, not supported by the Author. Oh Sure, he'll still give you
a key if you ask for it, but the latest version is several YEARS old. To
me, thats not exactly supported. Or, at the very least, it's an idle
project. I'd like to find (if I can) a good (preferrably free, but
shareware is OK) tosser written RECENTLY.

 DE>> and doens't handle Squish message base format,

 ml> and it likely never will... why? because all the necessary support is
 ml> available in other applications... it wasn't until recently that the
 ml> code for those original applications was released for open source
 ml> development... all existing support for SQU bases came from learning
 ml> about them the hard way since nothing official was ever relased in the
 ml> way of definitive structures and operational methodologies...

Actually, I remember YEARS ago I found a message base tool kit (mkmsg if
memory serves) that had Squish I/O support.

 DE>> which I've been toying with for a while and kind of like.
 DE>> Seems to be a little faster than Jam and a LOT faster
 DE>> than HMB :>

 ml> it is understandable that SQU may be somewhat faster than JAM... it is
 ml> especially so when one considers that JAM offers more features than
 ml> SQU...

Ok. I'm listening. The only features I seem to be able to see are the
features that all message bases have, namely ability to set a max # of
messages, a max AGE for messages, and so forth. And those are not really so
much of a feature of the JAM base as they are of the message base UTIL you
are using. Now if you know of some really cool thing I can do with Jam that
I cannot do with Squish then please, tell me what it is and how I do it.
I'm always happy to learn something new. And if such learning proves a
previous statement of mine incorrect, then I will simply say "Well, I
will have to pass that one off as ignorance". I'll be the first to
admit my mistake when it's proven to me.

 ml> as for being faster than HMB, as in many cases, this depends on the
 ml> implementation employed for maintaining HMB bases... HMB has its own
 ml> set of limits that other message base formats highly surpass...

Like the message base size (200MB Max, right?), eh? HMB is great for
Locals. Thats what I use for my Local Bases. I'm using JAM for echomail,
and for Usenet groups I've been playing with Squish (50/50 mix, Jam/Squish
currently).

 ml> one can also use SQL databases for message storage... these don't
 ml> have the same limits that JAM, SQU and other formats may have but
 ml> they are also not as fast, either... and that due to the very nature
 ml> and methodology of SQL databases and their implementations...
Well, if you are going to boil it down that far, then even a raw flat text
file could feasably be a message base. Very slow, and no features, but it
would work!

 ml> basically, as far as speed and capabilities, i'm saying that much
 ml> depends on the implementations and that in some cases, there's not
 ml> much that can be done to boost some formats capabilities and access
 ml> speeds...

Ok. Then as stated above. Tell me any tricks you know for Jam. If JAM
really has these extra features you speak of I'd love to hear them and how
to set them up/use them. Not to say I dis-believe you. Far from it. I
simply am saying "Ok. If you say it's true, I believe you. So show me
HOW".

Dan

... Black Holes are where God divided by 0.
---
* Origin: * THE INFORMATION HIGHWAY! * (1:3005/3)
SEEN-BY: 633/267 270
@PATH: 3005/3 128/148 140/1 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™.