At this point, you can't really write a Daemon that could have a significant impact on the way MercuryP operates - I haven't as yet opened up its innards in the way I have for MercuryS... GreyWall is a good example of the type of minute control that the new protocol-level event mechanism I have developed for Daemons allows, but I'm retrofitting the event mechanism on a module by module basis, and MercuryP hasn't been done yet (even for v4.5). It's on the list though.

That said, the sorting idea isn't a difficult option to add, so that seems like a reasonable compromise in the short term.

Cheers!

-- David --

Some of us Mercury32 users would like MercuryP to give users their emails in the order that Mercury received them (FIFO). With the seemingly random name assignment that is currently used one must use a FAT32 file system to have FIFO. With NTFS the files are presented in alphabetic order which results in them appearing mixed up. (See http://community.pmail.com/forums/484/ShowThread.aspx#484 for more details.)

It seems like it would be very simple to modify Mercury to have it assign a sequential name for the CNM files, like AAAAAAAA, AAAAAAAB, AAAAAAAC, ..., ZZZZZZZZ. (This would only be for files that Mercury needs to name and currently gives a seemingly random name.) At the rate of 1 million emails per day it would take 570 years before Mercury would have to reuse a name. Mercury already uses sequential naming schemes for other things (for example the SMTP connection ID is an 8 digit sequential hexadecimal number. Using a hexadecimal name like that at the rate of 1 million emails per day it would take 11 years before Mercury would have to reuse a name). For those people for whom FIFO does not matter this scheme should not bother them. For those of us for whom FIFO is very important a scheme like this would allow us to use FAT32 or NTFS.

-Paul

Sequential names aren't feasible for a number of historical reasons (not least that there too many setups out there who have used the random naming scheme for too long). I'm also rather reluctant to attach too much in the way of semantics to filenames - I did that once before and it became a trap.

Nonetheless, as already noted in the other thread, it's quite possible to implement sorting of the type you're asking for, and possibly other options too (such as sorting by size from smallest to largest, so smaller messages are retrieved more quickly) without having to change the file naming in any way at all. I'm planning to investigate that tonight.

Cheers!

-- David --

Please use tags, like what modules of Mercury a post refers to - it is a GIGANTIC aid for all newcomers.

This one defenitely, MercuryP [:)]

You could write a daemon (plugin) for Mercury that intercepts emails and stores them in whatever format you like, wherever you like.  I'm not aware of any examples, but the documentation for writing daemons is fairly complete.  If you're not programming savvy, any friend with experience writing DLLs should be able to write a daemon with little effort.

I am not a developer, but I have to agree with David that this isn't a mainstream option that would be long-term maintainable.  It sounds perfect for a daemon though.