httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maxime Petazzoni <>
Subject Re: mod_mbox development plan
Date Sun, 03 Jul 2005 11:18:58 GMT

> I believe the core goal is separation of data from presentation.  The
> standard reply is to use some kind of template language.  A glue.  Let
> it be PHP, XSLT, ClearSilver, or any of the other hundreds out there.
> Why do we want glue?
> I believe that XHTML, no matter how masterfully done, is messy.  Its not
> a good method to sort data into logical groupings.  Yes, CSS does allow
> some separation of the presentation, but I do not believe it is
> completely viable for all design desires.
> I believe that hand coded (X)HTML inside C source files is wrong.  It
> hurts developer time.  Why should I have to recompile my module, stop
> and start apache, just to change simple things like a font or the order
> of something?

+1. XML has the particularity to describe only the data, as opposed to
XHTML which stores data *and* structure information. XML semantics
allows us to represent mailing list data with mailing list data
semantics instead of web page semantics. Given mailing list semantics
in the problem space, you can then transform to any solution space
semantics using XSL.

According to me, this is the cleaner way of doing things (regarding
the module's source code).

> Alternatives welcome. We already have a patch that does XML+XSLT.

Except from the small XML structure change you suggested (removing
year grouping in mailing list month index, and detect it while doing
the XSL transformation), we have the patch.

> > Don't bother with the DTD -- just be sure it is well-formed.

Of course I will :) Writing a DTD may only be done when we'll have
settled on what we output (and how), and when I'll have time to do so
(or during a boring afternoon, something like this).

> >>    * 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)
> Just because we use XSL for some parts, it doesn't mean that we have to
> apply it to all output.  Data meant for ajax can easily be passed
> through, and not converted to XHTML.

I've made another AJAX experiment in order to check out on what DOM
our Javascript functions would operate when we send XML : is it on the
XML node tree, or on the XHTML resulting tree (after the XSL
transformation) ?

You can check it out at . It's the same as
the first one, except that I use an XML document and an XSL stylesheet
instead of direct XHTML.

The result is that Javascript operates on the XHTML tree, so after
every XSL transformation is done. This makes my client-side processing
argument absolutely void :)

> There are two type of caches here.  One is of the parsed XSL File.
> Another is a layer provided by mod_cache.  The first one should have
> an excellent hit rate, while like you mention, mod_cache would not.
> No slow down isn't truthful compared to a static file, but
> mod_transform can be pretty fast when the XSL cache is active.

+1 for the cache explanation. I was of course talking about the XSL
cache provided by mod_transform.

> Doing this kind of thing server-side gets us to (X)HTML. That is a
> better known quantity. I believe there is a better expectation for that
> to work on all browsers.
> Regardless of how we get there, I think the browser should be
> downloading XHTML.

Well, finally, I don't know which solution is best. If mod_transform
becomes part of HTTPd by the end of the summer, then I surely prefer
server-side processing. But if it does not, the 3rd party module
dependency will make me prefer the client-side processing solution.

- Sam

Maxime Petazzoni (
 -- gone crazy, back soon. leave message.

View raw message