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
