So the POP client is being built on top of an HTTP server? And I access it via a web browser pointed at localhost?
Does that sound crazy to anyone else? It makes me think the authors have a hammer (i.e. web development skills) and therefore think everything is a nail (i.e. a webpage).
If I have to install software anyway, I'd much rather it be a full fledged native client. One that looks, feels, installs, uninstalls, and is configured just like all the other native programs on my machine. I had such a program in the late 90s/early 2000s. It even had support for SMIME and PGP.
Honestly, on a desktop I'd almost rather use an HTML/JavaScript UI than a native UI. On the machine I'm using right now have the option of using iCal, Mail.app and Twitter's native desktop client. I find myself using Google Calendar, Gmail and Twitter's website instead.
Having tabs, back buttons, the ability to open things in new browser windows, the ability to bookmark and copy-and-paste links to different views of an app are all things that I like about web apps that aren't universal in native apps.
If you're the type of person who can actually get through the install process,[0] you're the type of person who doesn't care about having to access it via localhost.
There's nothing wrong with making a web mail client this way. Many people already access mail via their browser, so this is not drastically different. It also means they don't have to develop and test three different codebases.
I imagine they will get to the point of having the client wrapped for the platform so the user doesn't have to fudge around with it and can just click the icon and have it open in their browser (or the client's browser.)
The biggest advantage is cross compatibility. Setting up a http server in any mainstream language is very easy, when compared to the task of creating native UIs for each OS. Look at how much hate Swing, GTK and even Mozilla's XUL got before they went to great efforts to use the native UIs.
