With the release of Mercury v4.73, it became clear that it was time to start work on major developments within Mercury that are long overdue. The most obvious and immediately necessary of these is the complete separation of the user interface from the working processes at the core of the program. Under Windows 7, Windows Server 2008 and, we presume, upcoming versions of Windows, service processes can no longer have user interfaces that interact with the desktop, which makes configuring Mercury in these environments a bit fiddly. What is needed is a user interface that can run anywhere, connecting to the working processes to configure them: this would allow you to configure the copy of Mercury running on the server in your machine room from the comfort of your own desktop PC, or from home if there was an after-hours problem. Allied with this is the need to manage mailing lists remotely as well - I am building the new remote facilities in such a way that there will be a simple application allowing list moderators to manage just the lists for which they are responsible from anywhere on the Internet. For unlicensed copies of Mercury, the program will continue to run as an application with the full user interface built-in - and indeed, if you have a license, you can run the program as an application with its full UI *and* still configure it remotely. This ability to have the UI or not as you please is quite powerful and took quite a bit of effort.
After quite a bit of development over the last few months, Mercury is now in a state where the separation of UI and working core is complete. It is now possible to run Mercury as a service with no user interface, and configure it using the full user interface running as a separate process on the same machine: from this, it is a fairly short step to allow the configuration to be fully remote as well. After that, it's just making the consoles for the various processes available remotely and the job will be effectively done. One of the things that makes the process more time-consuming is the need to ensure that very high levels of security apply to the process, so everything is getting bullet-proofed and double-checked to that end.
In other areas, Mercury, like Pegasus Mail, will be migrating to use the industry-standard OpenSSL library for its secure communications, which should improve interoperability and will bring the new ability to use "real" SSL certificates (i.e, ones issued by CAs such as Verisign). As I remarked in a recent Pegasus Mail blog posting, the development of the new common message store for both programs is proceeding well and should finally come to fruition this year. A side-effect of the new message store will be that it will be possible for me to rework large parts of the MercuryI IMAP server that are currently limited by the old message store. The aim is to produce faster, more reliable IMAP service with support for a number of the more important modern IMAP extensions, such as SORT and IDLE.
Well that's it for now - time to get back to working on any of the thousands of things I seem to have piled up on my desktop. All my very best to you all!
-- David --