On Jul 2, 2005, at 7:46 PM, Maxime Petazzoni wrote:
The main goal of my SoC project is to enhance mod_mbox's interface by using newer web development techniques and/or technologies, while avoiding any noticeable slowdowns.
That's good, but keep in mind the general design principle to avoid doing things on the server that could be done on the client.
The first thing that has to be done is, of course, get rid of the hard coded HTML and switch to something more flexible. Two main solutions are available : - a template system such as ClearSilver - XML + XSLT
I guess I am having a hard time bridging that leap from goal to a fairly specific solution. What are the real advantages of being flexible on the server? I mean, as opposed to simply using a fixed data format with XHTML and class names?
Since I already have a good knowledge of XML and XSLT, I chose these technologies for mod_mbox's output. Making the necessary changes to mod_mbox was a good introduction to it's source code, and I already sent the resulting patch (also featuring email obfuscation). The DTD is not yet written for mod_mbox's XML output format because what has currently been done may need changes (I'm far from being an expert in XML data semantics).
Don't bother with the DTD -- just be sure it is well-formed.
XML output brings about another question : where should the XSL transformation be done ? Two solutions are available : - server side processing with mod_transform. No slowdown thanks to the XSLT caching feature. This solution has two main drawbacks : * The client receives HTML code instead of XML, which will make additional features such as dynamic interface (with AJAX) difficult or impossible to implement (since we don't know what the DOM tree will look like after the XSL transformation, we can't implement DOM dynamic updates) * mod_transform is not part of the HTTPd project yet. It needs to be compiled, installed and setup separately. Using server side processing would bring a dependency to an "unofficial" 3rd party module.
Also, "no slowdown due to caching" is only applicable for request patterns that involve frequent duplication of a small set. It doesn't work that way when the archive contains several million messages, since the cache hit rate will be too low to compensate for the transform cost.
- client side processing : just give the XML output and the XSLT to the client's browser, and let it manage the transformation itself. On the one hand, this solution allows nice (and wanted) features that AJAX could provide ; on the other hand, it requires an XSLT capable browser (Gecko-based).
This is not a problem with XHTML.
In the light of the above, I personally prefer the client-side processing solution. Anyway, I've tested and now know how to set up both of these solutions.
+1 to client-side.
The XML output is a good start, but it's not enough to make mod_mbox's interface good enough : we need more interactivity, especially when browsing mail threads. The AJAX (Asynchronous Javascript and XML) development technique is an interesting solution to this need. By providing a quick, neat and dynamic interface, it can make the archive browsing more user-friendly. I'm currently making some AJAX experiments (I've never used it before, but I'm here to learn :) in order to figure out what it can do for mod_mbox and how. I'm working on an interface mockup that I'll soon submit for review, too.
That sounds like a good plan to me. ....Roy
