Hello mark.

24 Mar 03 16:36, you wrote to me:
 DE>> I'd like to find (if I can) a good (preferrably free, but
 DE>> shareware is OK) tosser written RECENTLY.

 ml> why? if something is not broken and works as designed, why should a
 ml> new version have to be released every X months??? it doesn't make any
 ml> sense at all... you don't put a new engine in your car every 100000
 ml> miles just because there are new ones out, do you?
If FastEcho would support filenames beyond 8.3, I'd be sold and stuck. I
love it, but the fact is that it doens't support anything but the 8.3
format and since I'm using a Win32 bbs some of my message base files are
not 8.3 formated names. It's a pain in the A** to look at the config and
see: C:\BBS\ELE\MSGBASE\ALT_BB~3

Ok. so is that a message base file for:
alt.bbs.elebbs?
or
alt.bbs.ra?
or
alt.bbs.doors?
or
alt.bbs.lists?
or alt.bbs.allsysop?

Get the idea? :>

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

Point being it was there :>

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

Too bad no BBS software I've seen supports these features :>


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


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

Heh heh :> With a limit in the HMB of 16 MB, echomail and Usenet news
would fill the base fairly quickly :> so I used a base format that
doesn't have these limits for the bigger areas :>

 ml> yup! that's where we started, actually... native format for news and
 ml> email is plain ascii text with one blank line between the message
 ml> header and message body... mbox storage format stores all messages in
 ml> one ascii data file with four (4) ^A characters marking the end of one
 ml> message and the beginning of the other... slow? again, that depends on
 ml> the implementation...
Well, Seeking would likely be a little slower than other formats. And when
I was saying one file, I meant ONE FILE for ALL bases :> it COULD be
done that you have one file (400+MB) for ALL areas, Local, echomail,
Netmail, email, UseNet, etc...

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

I'm Familiar with the UUencoding method, and while I don't understand mime
quite as well, I do understand the size constraints :>

So I guess I'm back to square one here. I need a message tosser that
1) Supports Win32 Long File Names
2) Has a message base pack/purge/sort/index/etc.. feature
3) Will Auto-Export the messages.ra file for me, in the format I'd prefer.
I finally got FMail to export a file with all the echos, but regardless of
what I have told the stupid area format file, it always starts dumping all
areas at message base #201, leaving 1-200 empty except for the couple of
local areas defined. This, imho, is nuts and a VERY LARGE MINUS for using
FMail. too bad. I recall when FMail was a great tosser (shortly after it
first came out, when it was free still). Exceedingly fast. I was using
IMail at the time and FMail knocked IMail's socks off. FMail is still very
fast, but if it insists on making my messages.ra file have a 190+ area gap
between local and echomail/usenet areas, I doubt I'll be using it.
4) (optional. Nice, but not necessary) Read a fidonet nodelist
(text/v6/v7/etc...) and allow routing commands for mail based on nodelist
flags, or lack thereof.

Unless someone can either tell me how to fix FMail, or point me to another
util that will do the first three points, it looks like I may end up
writing one myself.

Not a pleasant thought, but not impossible.

Dan
... He's gone!  He's been dragged off! - Sulu
---