Moving from Mac Mail to Outlook Express

These days it's not too difficult to change email clients if need be. Most clients come with powerful import and export tools, allowing for a fairly smooth transition. This week, however, I ran into an exception when trying to move email messages from Mac Mail 2.0 to Outlook Express 6. The experience left me with the impression that these programs are bitter enemies and loathe the idea of interoperating with each other. Here's some instructions on how to make it work (note: you will also need Eudora 6.2+ free edition installed on the PC):

Starting in Mac Mail do the following for each mailbox you wish to transfer (In, Sent, Deleted, etc.):

1. Select all messages and choose File -> Save As from the main menu. Choose "Raw Message Source" as the format and a name for the group of messages and click the "Save" button. Even though there are no obvious "export" commands from Mac Mail, this will effectively create a file in standard mbox format. However, Outlook Express will not directly import this file type so we'll have to play with it a bit.
   
2. Transfer the file you just created to the PC.
3. Open the directory C:\Documents and Settings\[Account Name]\Application Data\Qualcomm\Eudora (you will need to go to the View tab under the Tools -> Folder Options menu and select "Show Hidden Files and Folders" to be able to view this folder).
4. If appropriate, rename the file you created in step 1 to match one of the mailboxes in this folder (In, Out, Junk, Trash, etc). Assign this file a .mbx extension.
5. Copy the file from the previous step into the folder you opened in step 3. (Important! Only do this if you don't mind overwriting the email in your Eudora application).
6. Open Eudora and view the mailbox you just copied. This will firmly establish your .mbx file as a Eurdora mailbox. Don't worry if the text in your messages doesn't look quite right - this will soon be remedied.
7. Open Outlook Express. Select File -> Import -> Messages from the main menu. Choose "Eudora Pro or Light" and go through the rest of the wizard. This should properly import all your messages from the selected mailbox into Outlook Express.

A twisted solution? Yes, but it's the only one that I could get to work! If you know of an easier one please post a comment detailing your experience.

The Challenge for Server-Side Java

I'll start with being up front about my Java background. In all honesty if given the choice between Java, .NET and PHP, Java would be my weakest subject. I've written a total of two relatively small Java projects at work and have read two Java related books (one detailing the syntax of the language and the other demonstrating how to use JSP). As such I'm not an expert with this technology, yet all the same I feel as if I've gleaned some observations throughout my limited experience that are worth sharing.

It's a rare thing to find Java being offered from your average web hosting company. Most of them advertise ASP.NET or PHP/PERL as part of their plans...but make no move to go beyond these options. Some of the managed, dedicated hosts (such as Rackspace) offer Java but only by way of do-whatever-you-want-with-your-root-account. And even if a viable Java host is located, the price for such a service tends to be comparatively high.

This is a problem. If server-side Java is to have a future, it must continually be opening itself to new audiences. With less options in small to mid-sized hosting environments, Java is sending an erroneous signal that it isn't as flexible or powerful as competing technologies. Is this because servlet administration is more expensive? To cut down the need for additional hardware, perhaps the JVM can be shared among several applications on one box (similar to the way that ASP.NET shares one worker process among many AppDomains)? Myservlethosting.com describes why a shared JVM might not be a good idea for production applications, even if it might save money on hardware:

A shared JVM is when you share your Java Virtual Machine with other clients on the server. You will use the same memory space as they do. This can mean it being less secure and less robust. Typically there is no security issues, but we felt that we should just mention it. Since you are sharing the JVM with other clients you will not have full control over starting and restarting the servlet engine. Typically a shared JVM is ok if your application is not in production or you are just developing it.

A private JVM is when you have your own servlet engine installed into your home directory and its dedicated to you and only you. This is great for serious developers that need the FULL control over the configuration files, start and restarting the engine, and much more...

I recognize that Java has other barriers to entry. But with tools like Eclipse and Netbeans and a thriving community in the JCP, many past complexities are starting to fade. Hopefully hosting availability for server-side Java will grow to the point where it is affordable, stable and inviting enough to catch the eye of any hesitant hobbyists or small businesses.