Re: [ql-users] Qeymail, last call for suggestions...

[James Hunkins]

Sounds very clean. I am looking forward to your program.

It should also fit very cleanly into the QDT environment, especially since you plan to use the pointer environment. QDT will also be able to take advantage of the standard config blocks and will eventually offer a 'free' to use installer based on scripts which you might like to adapt to your distribution (does not require QDT to run). This will be available sometime next year.

Have fun,
Jim

On Tuesday, November 12, 2002, at 06:57 AM, Dave P wrote:

On Mon, 11 Nov 2002, James Hunkins wrote:

I don't like the idea of a single file. Take a look at Microsoft's
email program - there have been many problems with the single file once
it gets too large. Things slow down, corruption is possible, and
trying to extract and save individual emails gets 'interesting'.

I don't like the idea of a single file either, because removing an email
from the middle of a file and closing up thew gap is slow if done on a
drive, or would exhaust memory. I don't want to divide email by date
either. Finally, I do not want to divide email by sender email, because
the penalty is that the ones who send most mail have the largest files and
slowest response.

Instead, I am aiming towards a subdirectory structure, thus:

inbox_index
inbox_1211020001
.
.
inbox_121102FFFF (ie can handle 65536 mails a day)
delet_index
delet_1211020001

etc...

I will also allow people to create their own folders and move mail between
folders.

Someone else mentioned the QL file limitations per directory. This
could become a problem for someone who gets a lot of emails. You might

I think if people really store that much mail, I will have it auto archive
mail, and inform the user. EG: on start up it can say "You have over
30,000 emails. Call Geeks Anonymous on..." *grins*

Also, are you aiming this at all users including floppy and microdrive
types?  If so, what happens if a user fills up a floppy, etc (for some
of us, this is a real possibility).

I will allow each folder to be on a different drive, so inbox could be on
flp1_ and others on flp#_ - all user-assignable.

I think it will be important to include mail backup facilities, just to be
on the safe side for everyone.

Dave