phil ringnalda

I’m writing a decoder for all this in Python and may have time to do a wxWindows blog browser so Windows and Linux people can join in … the importer for bzero will come first though ;-)

Update: it works!

http://www.myelin.co.nz/gazer/

I’m now storing my Blogger-driven site in RSS 2.0 and the ”files.xml” format. Could one of you guys test it with your apps? I’ve got a main RSS file and a list of archive files. On the last one, I’ve added titles to each file (using the Dublin Core title element) — I hope this is legal.

Bravo! I’d idly thought about Blogger (it would work for an MT import format for more than 999 entries, where the current scheme fails), but hadn’t got past idle thought. BlogGazer 0.01 completely fails to read your blog, since it’s a pretty radical departure from the files.xml format and 0.01 doesn’t even tolerate my pubDates that don’t have the weekday in the date, but it’s still early days.

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

Phil I just got back from NY, so this has to be quick. There is no spec for files.xml. However I’m sure when there is one, size will be optional. Radio doesn’t need it, particularly, other than to be able to tell if a file changed, but the mod date should do the trick.

I can’t really put modification dates, sizes, or what have you in my Blogger-generated archive file. Just the file paths and titles.

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?

BlogGazer uses the pubDate element in the RSS to determine date … I assume that’s how BlogBrowser does it as well.

Are you guys talking about the same dates? I’m pretty sure Mark means the years and months in the tree menu on the left side, which surely aren’t coming from pubDate (since otherwise you would have to download and parse every bit of RSS before you could display anything, and it doesn’t look like BlogGazer’s doing that). Don’t those come from files.xml?

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.

Yes, I mean the tree menu, which as Phil said, clearly isn’t coming from pubDate.

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. :-( )