People who are interested in the software shouldn’t have to read the acres of prose in the mod_atom intro, so I’ll just keep this one up to date.
The code is currently here.
2007/06/27 · Updated iterator.c to fix pkeane’s bug while retaining concurrency safety.
Tested on a vanilla Debian box, and the compiler there emitted a couple of warnings one of which turned out to be an actual bug (that the unit tests hadn’t caught, sigh). Whatever, it ran fine. Like I said, programs written in the C language are portable. Write Once Run Anywhere, baby. Well, with APR anyhow.
2007/06/29 ·
Collection paging now seems to work (but only with “next” links).
(BTW, did you know you can’t subtract one apr_time_t
from another
and expect to return the result in a qsort
comparator? I wanna
go back to Ruby.)
The README file is no longer just a copy of Josh Rotenberg’s.
2007/07/10 · Ouf, what a struggle. The last piece, supporting PUT on a Media Resource, and consequently updating its Media Link Entry and making sure that collection got sorted, chewed up all my time during the Berlin week when I wasn’t child-minding or wedding-going or drinking beer. Also, I had to add a bunch of tests to the Ape to cover this function.
On the downside, the routine that generates the XML for a Collection feed now has eleven (!) arguments, and thus screams out for refactoring.
On the upside, a lot of mod_atom’s work consists of pulling apart and
gluing together directory paths for entries, collections, and so on. There
are a lot of ways to get the slashes wrong, so I had lots of bugs where paths
had two adjacent slashes, or worse, none. So I wrote a nice little
join
routine that glues segments together with only one slash
regardless of how sloppy you are passing them in; this allowed simplifications
here and there all over the place and is a lot more robust.
Of course, wiring it in made many unit
tests fail, and then lots of Ape tests too, but this is what tests are for,
right?
I think I’m going to park the mod_atom code at Google Code or somewhere for the moment and call this release 0.7. The idea is that 0.8 will add HTML generation and 0.9 non-destructive editing.
2007/07/11 ·
It’s parked, for the moment anyhow, at
Google Code. I had a little
trouble because on OS X, the svn you get from Fink doesn’t seem to have ssl.
That’s OK, it turns out Collabnet has
up-to-date OS X
binaries. Thanks to Greg Stein for the pointer; he also noted that I
might want to switch mod_atom to use a few simple directives inside an
httpd-config <Location>
block, then I wouldn’t have to do my own
prefix mapping. I’ll have to think about that one a bit; sure sounds
plausible.
2007/07/25 ·
I started working on sanitization code. There’s the beginnings of a
discussion on the issues over on the googlecode
Wiki.
For now, I only try to sanitize text constructs with
type="xhtml"
, with a whitelist-based design (and whitelists, too)
stolen from the
Universal Feed
Parser.
That code’s checked in, and there are tests for it in the Ape.
I still haven’t figured out what to do about type="html"
.
Comment feed for ongoing:
From: David Hall (Jun 27 2007, at 17:48)
Don't you mean 06/27?
[link]
From: pkeane (Jun 27 2007, at 21:48)
And indeed, I now have it up and running and putting it through it's APE paces. (Hope you don't mind me using tbray.org/ape since I do not have an easy way to get APE up and running just now). Many thanks for this code -- I'd been waiting/hoping for a mod_atom . I'm hoping/planning to build a 'servicified' CMS on top of it. Wondering if there's a role for Subversion in there somewhere, apropos "I think it would be better, in all cases, to copy the data aside, uh, somewhere."?
-peter keane
[link]
From: Andrew Sidwell (Jun 30 2007, at 19:25)
I think subversion would not be well suited -- git seems like a perfect match, however.
[link]