httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roy T. Fielding <>
Subject Re: mod_mbox development plan
Date Sun, 03 Jul 2005 20:49:13 GMT
On Jul 3, 2005, at 1:29 AM, Paul Querna wrote:
> I believe the core goal is separation of data from presentation.

No, the core goal is to provide an ultra-efficient interface to
large mail archives.  The data is already available in mbox form.

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

XSLT isn't a template language -- it is a transformation engine.

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

Use CSS.  CSS files are template presentation mechanisms that can
be specialized on a per-site basis regardless of the data sent from
server to browser.  Have a look at WordPress to see how effective
this can be without requiring additional overhead on the server.
They use PHP as a templating mechanism, but most people ignore that
and simply modify the css files to show or hide data as they wish.

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

I don't agree.  It is far less painful than doing XML with browser
negotiation and high-overhead transforms on the server-side.  We
are not talking about an arbitrary data interface wherein the admin
needs to configure the placement and names of data fields. Mail
messages have their own naming mechanism and data items can be
selectively configured for delivery using a simple configuration
mechanism.  The "template" mechanism can be limited to header and
footer files without any loss of generality to the user.

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

Agreed.  Just keep an open mind, try the alternatives, and be prepared
to defend the implementation on the basis of its performance.

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

Right, the ajax interface can be a completely separate tree of URIs
that only needs to worry about its particular style of index/threading.

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

XSL support?  Forget that -- I was talking about CSS and ajax.
XHTML works on all relevant browsers and looks as good as it gets
on Lynx/links.  We only have to make it look pretty on Firefox,
Safari, and Konqueror.  And there is no problem at all if the ajax
stuff only works on Firefox.

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

Then it doesn't make any sense to use XSLT.  I wouldn't use a
sledge-hammer for tapping nails.


View raw message