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

 DE> I meant to say, not supported by the Author.

i guess that depends on what one calls "support"... this is also
one of the reasons why there are support teams in place... one author
cannot field all questions from thousands of people and maintain his
development, desire, or even life outside these boxes...

 DE> Oh Sure, he'll still give you a key if you ask for it, but
 DE> the latest version is several YEARS old.

yeah, and it still works and performs admirably...

 DE> To me, thats not exactly supported. Or, at the very least,
 DE> it's an idle project.

i guess idle may be a valid classification...

 DE> I'd like to find (if I can) a good (preferrably free, but shareware
 DE> is OK) tosser written RECENTLY.

why? if something is not broken and works as designed, why should a new
version have to be released every X months??? it doesn't make any sense at
all... you don't put a new engine in your car every 100000 miles just
because there are new ones out, do you?

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

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

yes, it does have support but not "official" support from the
creator of the squish base format... squish support was reverse
engineered... jam support was a bit easier as there was at least a code
library released and with that in hand, mark may wrote his own jam support
code... hmb support was reverse engineered, as well...

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

 DE> Ok. I'm listening. The only features I seem to be able to see
 DE> are the features that all message bases have, namely ability
 DE> to set a max # of messages, a max AGE for messages, and so
 DE> forth.

no, those are not features, really... i'm talking about things like being
able to have messages encrypted in the base with control lines telling the
type of encryption and such so that they may be decrypted on the fly when
viewed... compression, too... it is also possible to link in external
objects like picture and music files... the design allows for this type of
stuff in the header control fields...

 DE> And those are not really so much of a feature of the
 DE> JAM base as they are of the message base UTIL you are using.
 DE> Now if you know of some really cool thing I can do with Jam
 DE> that I cannot do with Squish then please, tell me what it is
 DE> and how I do it.

there are a lot of things that can be done but unless the methods have been
developed, i don't know how to tell you how to do them...

 DE> I'm always happy to learn something new. And
 DE> if such learning proves a previous statement of mine
 DE> incorrect, then I will simply say "Well, I will have to pass
 DE> that one off as ignorance". I'll be the first to admit my
 DE> mistake when it's proven to me.

not a problem... have you looked at the structures for JAM bases? what
about Squish bases? what about the code libraries and what they do and how
they can possibly be used to add additional functionality? i keep hearing
that SQU is supposed to be so good because you can limit the number of
messages and it'll pack old ones out during the toss phase by locating the
old ones and tossing the new messages into those slots in the data files...
years ago, when drivespace was expensive, this may have been a desireable
feature to have... i know that some bbs systems like WWIV and TAG (IIRC)
had this feature but the major fault i find with it is that one can all too
easily allow for too small a number of messages and then one looses all
older messages and possibly even new ones during this particular feature
phase... even so, there was really no need for it if one had their system
perform message base maintanence at preset times (ie: daily or weekly)...

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

 DE> Like the message base size (200MB Max, right?),

no... 16Meg max, actually... goldbase is a modified hmb format and may have
a 200meg limit, though...

 DE> eh? HMB is great for Locals. Thats what I use for my Local
 DE> Bases. I'm using JAM for echomail, and for Usenet groups
 DE> I've been playing with Squish (50/50 mix, Jam/Squish currently).

i see no difference in using one format over another for certain types of
messages, really... local, echo, news, email, netmail, whatever... they are
all simple messages and will fit in to most message base formats...

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

 DE> Well, if you are going to boil it down that far, then even a
 DE> raw flat text file could feasably be a message base. Very
 DE> slow, and no features, but it would work!

yup! that's where we started, actually... native format for news and email
is plain ascii text with one blank line between the message header and
message body... mbox storage format stores all messages in one ascii data
file with four (4) ^A characters marking the end of one message and the
beginning of the other... slow? again, that depends on the
implementation...

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

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

see above... i wrote about a few... however, i've never seen anything that
actually implemented them... the internet swept thru fidonet and really
hurt a lot of things... even now, most all internet messages are plain
ascii text files... local storage is another matter... MIME and UUencoding
are methods of encoding binary data into 7bit ascii data for transmittal...
and you gain ~1/3rd the size of the binary when doing so... (ie: a 3meg
file gives a 4meg attachment once encoded)

)\/(ark