Hello mark.

25 Mar 03 11:10, you wrote to me:

 ml> ok, so don't name them like that... FE, by default, will generate a
 ml> name for them when areas are autoadded... however, it is as bad or
 ml> worse to look in the config and see G:\JAM\FIDO9\FEF656FA and have to
 ml> 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? :>

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

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

 ml> the dots in those names are to indicate directories and directory
 ml> structures... you don't have to shove 32 areas all into one directory
 ml> and probably shouldn't put any more than 30 in one area... this is for
 ml> speed consideration for the OS reading the FAT tables... there is/was
 ml> a penalty once an area hit 128 (?) files in a directory... this is why
 ml> *.MSG (SDM) areas and one file per message area get slow...
thats not the point. Fastecho is not naming them, I am. And I was not aware
of any such problems in file access as you describe. To me the BBS has
always seemed fine with everything in c:\bbs\ele\msgbase. I suppose I could
look into doing it like that, but if I was to do it that way, how would I
store alt.bbs vs alt.bbs.lists? i.e. the file would be
c:\bbs\ele\msgbase\usenet\alt\bbs for alt.bbs and
c:\bbs\ele\msgbase\usenet\alt\bbs\lists for alt.bbs.lists. So, now comes
the interesting point. I'm getting a file and a directory of the same name
in the same place. Doesn't work very well. Perhaps I am just not seeing the
way you are describing it (or trying to) but that is the problem I see with
your naming schemes so far. If you have overcome this, I'm all ears.

 ml> as for 8.3 being a restriction... i tend to see it more as teaching
 ml> me
 ml> about how to build a hierarchy and to catagorize or pigeonhole where
 ml> certain items should be placed... it also lets me build a system that
 ml> can be accessed much faster than one that carries everything in one
 ml> central location...
I have always found one central location to be very easy to manage. And I
admit, names like FE981252 are not the most descriptive. But I can live
with that. Call me lazy. I don't mind those since *I* don't have to
remember what they are. I do slowly convert them into more meaningful
names, but it's a low priority item.



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

The only time the tosser has to deal with HMB is for Netmail or for message
base maint. ALL Fido echos go to JAM bases.

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

I know the feeling on that one.

 ml> oh, and don't forget the limits of the operating system of the
 ml> harddrive format... just because the os or the format can handle one
 ml> file up to 32gig or 4tera doesn't mean that the message base format's
 ml> indexes can count or point that high...
That would be ONE BIG MESSAGE BASE DATABASE! :> What, all messages from
all echos for the past 20 years or something? :>

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

I would not use 4GB in an intel based machine. Thats rediclous. 1GB is plenty.


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

Actually, it's 3 into 4, but that is beside the point :> It still
increases the size. Going 2 into 3 would result in a roughly 50% size
increase. 3 to 4 is a roughly 33% increase :>

 DE>> 1) Supports Win32 Long File Names

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

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

 ml> commonly available...

I would hope so :>
 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.

 ml> well, you have to look at the reasoning why they and several others do
 ml> this... since HMB areas can only be numbered 1-200, they reserved
 ml> 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.

 ml> i've used both and don't remember any real speed differences... but i,
 ml> too, went from imail to fmail and then to fastecho... if it wasn't for
 ml> imail, i'd likely never have gotten into fidonet as qmail from the
 ml> qbbs stuff was giving me fits with ra... got it to work one way or the
 ml> 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.

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

That I can see and it will eventually happen here. But it's a low priority.

 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.

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

Not Riva, but Capablity flags. For example, route any mail to someone who
flys the IBN flag to them directly. Anyone NOT flying that flag gets mail
routed through my hub.

 ml> in any case, this last one also deals with how you handle routing
 ml> passthru mail... some use their tosser as you are seemingly
 ml> indicating
 ml> that you want to do... others mailers handle their routing and there's
 ml> a third group that route some stuff with their tosser and the rest
 ml> with their mailer...
Well since Argus won't handle ANY routing, for me it has to be done via tosser.

 ml> could you be a bit more specific with your example about routing
 ml> based on a flag??
See Above. I just did :>

 ml> well, since this is the allfix_help echo, i don't think that fmail
 ml> support is available in here >  maybe in the fmail
support echo?
I finally got FMail working ok. Not great, but works good enough. Now if
you can show me a good way to handle your file/dir naming conventions
above, then I could likely stick with FastEcho and not need to register
FMail (which would make me happy).

Dan

... To every rule there is an exception, and vice versa.
---