httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <c...@force-elite.com>
Subject Re: mod_mbox development plan
Date Sun, 03 Jul 2005 08:29:09 GMT
Roy T. Fielding wrote:
> 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?

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?

This is where the jump to a specific solution from the goal came.  We
could debate the possible solutions for months, even write our own
language, but the simple answer is that none of them are perfect, but I
believe most people will agree that doing raw XHTML even with masterful
CSS is painful.

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

>> 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)

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.

>>
>>    * 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.

For what its worth, the holders of the copyright on that module are all
HTTPD committers. I don't believe it would be a significant issue to
relicense it if people felt it was necessary.

> 
> 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.

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.

>>  - 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.

Good Luck.  I don't want to spend the summer testing XSL support on 6 or
7 different browsers/versions.  This is not even counting alternative
browsers like Lynx, which have no support at all for XSLT on the client
side.

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.

-Paul


Mime
View raw message