Dave: could you make the size=”” part of files.xml optional in the spec, so apps won’t depend on it being there, or do you need it for Radio’s implementation? It’ll be somewhere between hard and impossible to do in other apps (I just hand-coded my files.xml to get around the problem, but that keeps me from doing it as a live archive – if I have to I can do files.xml as a PHP script that reads the directory and fills in the file sizes, but that really complicates the process).
]]>Also, looking at the screen shot of BlogBrowser, it looks like entry dates are inferred from the file paths listed. Is this really a good idea? What if someone stores things using a different directory hierarchy? (OK, forget the ”what if” — that’s what I’m actually doing, by necessity of how Blogger dumps its files loose into one directory.)
And, well, if the intent is to express hierarchy, shouldn’t we be using OPML?
]]>And isn’t he screwed for that, since Blogger is a complete bitch to work with in the archive template? The best thing I can think of is to publish the Blogger archive template as PHP, with a bit of code to parse Blogger’s date ranges and turn them into creation dates, tell your server to parse it as PHP in .htaccess, and then use mod_rewrite to serve up Blogger’s archive files for requests for /2002/10.xml. It’s not very satisfactory, but then we are talking about Blogger-produced archives, so you can’t expect to be very happy with it no matter what.
]]>I really don’t want to have Blogger generating a PHP file. I like the fact that I can use the same XSLT to generate both content and archive pages. (Though it could use a lot of refactoring… not enough time lately. :-( )
]]>