ryochiji's blog

DHTMLization of IlohaMail

I spent all night last night (literally) working on DHTMLizing (or GMailifying, if you prefer) IlohaMail. I'm starting with the message listing, which is about half way complete. At the moment, I can flip through pages, do a "quick search", apply filters, all without reloading the page (i.e. just through XMLHttpRequest). Some thoughts...
Show Rest of Post

posted in Devel at 15:59[1276 comments | View | Add Comment ] [PermaLink] [Trackback]

I hate IE, I hate IE, I hate IE. I don't care if IE has shitty security (esp. because I don't use it), but it's a real bitch to develop for. I'm developing on Firefox because it has useful tools like the DOM viewer and JavaScript console, and in general, what I do for Firefox works fine with Safari (so far). But then I go to a Windoze machine, test on IE, and it all blows apart. To itemize further, things I hate about iE:
- Lack of any useful development/debugging tools (are there plugins?)
- The object model is different to Firefox/Safari is annoying ways
- The general "we'll do it our own wacky/shitty way" vibe I get...
PHP code reuse has been very, very high. I've hardly had to write any new PHP code, with the exception of a couple of functions to output XML. The nice thing is, the internal data architecture is actually quite good. To simplify, data destined for the message listing goes from raw IMAP -> IlohaMail IMAP Library Objects -> Display Data Packets. The Display Data Packets contain just the fields required for the message listing, and is in a compact array. At the moment, I'm converting the Data Packets to HTML (for non-JavaScript mode), to JavaScript arrays (for medium JS-usage), or XML (for DHTML mode).
JavaScript code reuse has also been very high. The display-layer JS code is practically identical, the only difference being, I'm now working with XML/DOM objects, instead of JS arrays.
Fast methods for accessing XML objects seems to be lacking (as far as I can see). Apple's sample code using XMLHttpRequest uses the getElementsByTagName method, which as far as I can tell, traverses the entire DOM tree below the node you invoke it from (i.e. potentially slow and inefficient). Since, I know what the structure of the XML data is before hand, I'm using faster (but less reliable and less cross-browser compatible) methods. One is to access by array index, which is fast but subject to such annoyances as Firefox and IE starting at different indices. I also wrote a simple alternative to getElementsByTagName that simply looks at the immediate children of a node, instead of traversing down the entire tree.
The next major problem I need to solve is browser-side object caching. So you look at one page of messages, and go to the next. Ideally, when you go back to the first page, you won't need to reload any data at all. The problem is, IMAP clients should never assume to be the sole client, which means the browser has to check with the server to see if there've been any chages. So we do that, and say there were changes. Now we have to make a second request to fetch the updated data. The fact that IMAP doesn't keep track of modification date/times across sessions makes the problem slightly more complicated than other similar caching issues that otherwise may seem similar...
Wouldn't it be cool if you could create new calendar entries by simply clicking in a blank area, and dragging the mouse (like you do in iCal)? A friend of mine created a pure DHTML drag&drop capable interface, although it currently only works in Firefox/Mozilla. If he finds a way to make it cross platform, some such sexy feature may appear in IlohaMail's calendar...
One fairly cool feature that XMLHttpRequest will enable is dynamic previews in the message listing. Simply click on a widget, and it'll show you a short preview of the message, without having to open the entire thing.