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?

 DE> If FastEcho would support filenames beyond 8.3, I'd be sold
 DE> and stuck. I love it, but the fact is that it doens't support
 DE> anything but the 8.3 format and since I'm using a Win32 bbs
 DE> some of my message base files are not 8.3 formated names. It's
 DE> a pain in the A** to look at the config and see:
 DE> C:\BBS\ELE\MSGBASE\ALT_BB~3

ok, so don't name them like that... FE, by default, will generate a name
for them when areas are autoadded... however, it is as bad or worse to look
in the config and see G:\JAM\FIDO9\FEF656FA and have to figure out that
that is the LINUX-USER echo...

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

 DE> Get the idea? :>

yeah, i see that you are not using a hierarchy of directories for your
message areas...

  ie: g:\jam\alt\bbs\elebbs
      g:\jam\alt\bbs\ra
      g:\jam\alt\bbs\doors
      g:\jam\alt\bbs\lists
      g:\jam\alt\bbs\allsysop
      g:\jam\alt\something\else
      g:\jam\comp\bbs\waffle

the dots in those names are to indicate directories and directory
structures... you don't have to shove 32 areas all into one directory and
probably shouldn't put any more than 30 in one area... this is for speed
consideration for the OS reading the FAT tables... there is/was a penalty
once an area hit 128 (?) files in a directory... this is why *.MSG (SDM)
areas and one file per message area get slow...

as for 8.3 being a restriction... i tend to see it more as teaching me
about how to build a hierarchy and to catagorize or pigeonhole where
certain items should be placed... it also lets me build a system that can
be accessed much faster than one that carries everything in one central
location...

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

 DE> Point being it was there :>

but it was not official support... even mark may's oop library has
limitations on some of the message base formats that are not there in the
specification or in the creator's documentation...

ie: this snip from the docs of one of my MKSMG based apps...

===== snip =====

Message posting size may not be a question for you and your setup. However,
I feel that you should know that PostIt does have "some"
limitations in its capability to post large files.

  MSG - unlimited size (will use up to 4Gig of diskspace for temp buffer)
  JAM - unlimited size (will use up to 4Gig of diskspace for temp buffer)
  SQU - approximate 32K limitation
  HMB - approximate 16K limitation
  EZY - approximate 16K limitation

The above limitations are imposed by the library of routines that I am
using. They may be removed or increased in size in future versions of the
routines or PostIt. At this time, PostIt will just truncate any postings
over the above stated limits without notification. [...]

===== snip =====

sure, i could (and had actually tentatively planned on) sit(ting) down and
make(ing) the needed changes so that the other message base formats used
the tempfile oop methods that mark used with JAM and MSG and build in a max
limit that would allod for one message of the bases max size to be posted
(HMB can have one message of 16Meg but since that the max size of the base,
that's the only message that can be in it)...

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

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

my point... no one has taken the time to look at what they have and what it
can do... they're too busy looking around them at all the other stuff that
others are creating and jumping from one lilly pad to the next... almost
reminds me of homer simpson... "well, i'm looking at... oooooooooooooo
donuts!" and how he's so easliy distracted from what he has or is
doing and pulled right into something else...

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

 DE> Interesting Idea. But HDD space is hardly at a premium
 DE> now'a'days. the BBS machine here has a 40GB HDD that was very
 DE> cheap :>

that's what i said... SQU has this built in... autopacking, i believe they
call it... supposedly one of SQU's big features... however, not many people
seem to even know about it much less use it...

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

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

ok, so why even use HMB at all? why make your tosser have to switch gears
during its operation? once you get up to speed, maintain it! there's enough
other things out there that will cause a loss of speed during the
operations... ie: opening and closing the bases to put messages in them...
this is why some folk like to sort their mail PKTs before they toss them...
that way, they can toss all of alt.bbs.ra in one go and then move on to the
next base... i like sorting the areas together but i prefer to keep them in
the order in which they arrive on system rather than in chronological order
because the format doesn't allow for accurate time stamping and many folk
use local time with no UTC offset indicator...

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

 DE> Well, Seeking would likely be a little slower than other
 DE> formats. And when I was saying one file, I meant ONE FILE for
 DE> ALL bases :> it COULD be done that you have one file (400+MB)
 DE> for ALL areas, Local, echomail, Netmail, email, UseNet, etc...

there are methods of creating indexes for ascii files... as for having all
the areas in one database file, i see the benefits and the drawbacks...
i've lost a full hmb before... 200 areas gone... poof! right into the
bitbucket... on the other hand, i've lost one or two JAM areas but not the
entire base...

oh, and don't forget the limits of the operating system of the harddrive
format... just because the os or the format can handle one file up to 32gig
or 4tera doesn't mean that the message base format's indexes can count or
point that high...

there is a point of diminishing returns... once a database gets so large,
it takes as long or longer to search thru it... that's the point to split
it into seperate bases... just like memory in your machine(s)... sure, the
machine may handle 4Gig of RAM but is it really helping it to go fast or is
it another behind the back sneak that intel and others are pulling (like
the winmodems and winprinters) to give the processor something to do all
the time?

 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)

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

they are basically the same thing... and its not a size constraint...
converting 2 characters into 3 is always going to make the resultant output
larger than the input was...

 DE> So I guess I'm back to square one here. I need a message
 DE> tosser that
 DE> 1) Supports Win32 Long File Names

why? i just showed you how to set up a hierarchy of directories for the
message bases... long filenames are not a necessity, are they? i mean, are
they /really/ =needed= just because another piece of software can handle
them? surely that piece of software can also handle 8.3s? surely that piece
of software doesn't base the display name of an area on the filename used
to store the areas data?

 DE> 2) Has a message base pack/purge/sort/index/etc.. feature

commonly available...

 DE> 3) Will Auto-Export the messages.ra file for me, in the format
 DE> I'd prefer. I finally got FMail to export a file with all the
 DE> echos, but regardless of what I have told the stupid area
 DE> format file, it always starts dumping all areas at message
 DE> base #201, leaving 1-200 empty except for the couple of local
 DE> areas defined.

well, you have to look at the reasoning why they and several others do
this... since HMB areas can only be numbered 1-200, they reserved those
areas for HMB only...

 DE> This, imho, is nuts and a VERY LARGE MINUS for using FMail.
 DE> too bad. I recall when FMail was a great tosser (shortly after
 DE> it first came out, when it was free still). Exceedingly fast.
 DE> I was using IMail at the time and FMail knocked IMail's socks
 DE> off.

i've used both and don't remember any real speed differences... but i, too,
went from imail to fmail and then to fastecho... if it wasn't for imail,
i'd likely never have gotten into fidonet as qmail from the qbbs stuff was
giving me fits with ra... got it to work one way or the other but not both,
import or export...

 DE> FMail is still very fast, but if it insists on making my
 DE> messages.ra file have a 190+ area gap between local and
 DE> echomail/usenet areas, I doubt I'll be using it.

what's wrong with a gap in the area numbering? ra can/will display the
areas all tight up together in a sequential fashion without the gap if done
right... myself? i prefer the gaps because then i can tell folk that the
space oriented areas are in the 300's, the news groups are in the 1000's,
the political areas are in the 2000's, etc... again, its another way of
catagorizing and seperating things in a logical method...

 DE> 4) (optional. Nice, but not necessary) Read a fidonet nodelist
 DE> (text/v6/v7/etc...) and allow routing commands for mail based
 DE> on nodelist flags, or lack thereof.

i think see the reasoning behind this desire but without a more specific
example, i'm not sure... i don't think you are talking about the RVIA stuff
in the nodelist but if you are, you should know that the testing period for
it has expired and that it should already have been removed from the
nodelist... besides, the phonebook isn't where you go to find a map of
directions to someone's house, is it?

in any case, this last one also deals with how you handle routing passthru
mail... some use their tosser as you are seemingly indicating that you want
to do... others mailers handle their routing and there's a third group that
route some stuff with their tosser and the rest with their mailer...

could you be a bit more specific with your example about routing based on a flag??

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

well, since this is the allfix_help echo, i don't think that fmail support
is available in here >  maybe in the fmail support echo?

 DE> Not a pleasant thought, but not impossible.

i agree... i've started to do the same thing a time or two, myself... one
of the biggest things that held me back was not wanting to be swamped with
support questions and such... if i'm coding something, that's what i'm
doing... and i test it to death... the beta team for my PostIt application
had a really hard time locating any bugs... a few times i actually coded
"fake bugs" into the app to give them something to find so they
wouldn't just drop out due to no incentive... i couldn't help it... i just
had to make it right in all aspects before others got it... there were at
least two legitimate bugs found that wouldn't have been found if it weren't
for others... one was a desqview video buffer bug and the other was with
using dashes within a parameter in my custom command line parser... there
were a few other items reported but they were things that i had to change
in the flow rather than true bugs...

)\/(ark