The Eighty-Twenty Solution

I started implementing Conditional-GET support I've been relying on Charles Miller's HTTP Conditional Get for RSS Hackers, along with Mark Paschal's correction. I went for a pretty ignorant implementation; after I generate a flavor (RSS, Atom, or HTML), I do an MD5 checksum on the result and use that as the ETag. I also query the entrylist that I'm rendering for the last modified date to get the Last-Modified header. My rendering code currently looks like this:

(define flavor-set `(("atom" . ,atom-flavor)
                     ("html" . ,html-flavor)
                     ("rss" . ,rss-flavor)))

(define (apply-flavor entrylist query flavor mode)
  ; look up the renderer and dispatch if found
  (let ((dispatch (assoc flavor flavor-set)))
    (if (pair? dispatch)
        ((cdr dispatch) entrylist query mode)
        (list "Content-Type: text/plain\n\n"
              (format "Don't know flavor ~A" flavor)))))

Essentially, it's a table driven dispatch, where each of the flavor functions expect an entrylist, which is a list of blog entries (each entry is actually an atom:feed), the query structure, which is parsed from the URL's path and is the query that was used to generate the entrylist, and a mode string, which comes from the URL's query string. I already have methods to ask a feed for its last modified date, and I can save off the result of calling the dispatch method, run an MD5 checksum on it, and then decide whether to send the content and a 200, or just send a 304 with no content. One small problem here is that my flavor methods currently generate some HTTP headers, and the way I read it, those don't factor into the ETag calculation, so I have to strip them. In one way, it seems like bad isolation to have the flavors generate any HTTP headers, but on the other hand, some headers (X-Pingback comes to mind) require information that only the flavor generator has.

John Morales made a comment on Dare's post on the underlying complexity in XML., I think that the "simple config file" use case for XML is actually pretty bogus, it's not very simple compared to say, INI files. Now I realize that you could in fact have a heirarchical configuration, which INI files suck at, but OTOH, it's much easier to fat-finger an XML file than an INI file. The "liberal vs. draconian" parsing attitude plays very much into the use case here. It's not so much a case of XML being built to serve many masters as people regarding it as the format of first choice. I'm curious to see Dare's guidelines, but I think that one of them should certainly be to not consider XML as the preferred solution for every serialization problem. Personally, I miss INI files, and I think that the omission of something equivalent to the java.util.Properties class is a big oversight in the FCL.

As far as John's XSLT criticism goes, I don't understand where you're going with the proposed alternative "Robust data naming system with transformations built into the core technology". To me, the chief problem with XSLT is that it's incredibly verbose and yet doesn't go far enough towards being a full language; XSLT is terrible at manipulating text content, for instance. I think Adam Bosworth said something like "XSLT is a functional language without any of the constructs that make functional languages useful", and I think that's pretty apt. I think that separating the core of XML from transformations is a source of strength, just like separating schema definition from the core is a strength. Don't like XSLT? Build another transformation language. Don't like XML Schema? Use RELAX-NG, or DTD, or Schematron.