httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roy T. Fielding <field...@gbiv.com>
Subject Re: mod_mbox development plan
Date Sun, 03 Jul 2005 04:46:16 GMT
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


Mime
View raw message