It’s been leveled up to the Protocol-13 draft level and the source is available. While I’m still massively unsatisfied, the Ape as it stands today is actually pretty useful.

What’s Wrong · The Ape is about 2,000 lines of Ruby that, in a meandering stream-of-consciousness sort of way, walks something that claims to be an APP server through its paces. Basically, I’ve developed it by sketching in a few initial tests, running it against a lot of different APP servers, and adding tests to cover the weird shit I observe.

What the Ape should be is a big portfolio of test cases, known problems that occur, with an easy way to add new ones that doesn’t involve writing ad-hoc Ruby code. [Credit for this idea to Sam Ruby.] Trouble is, I’ve started to implement this about three times now and haven’t come up with a good way of encoding either the test cases or the expected results. I haven’t given up, though.

For another excellent approach, check out Joe Gregorio’s APP Test Client, which has an actual GUI, and is probably quite a bit more useful than the Ape for zeroing on on some protocol pain point you’re trying to debug.

What’s OK · The Ape actually does a reasonably-OK job of characterizing an APP server implementation in a hands-off, automated way. It tries out the most obvious things an APP client would want to do: Fetch the service doc, find collections to post to, post an entry, update the entry, delete the entry, post a graphic, delete the graphic. Most obviously, it complains about errors, but along the way, it reports on what the server actually does in a lot of places where the behavior isn’t tightly constrained by the APP spec: slug, foreign markup, categories, content round-tripping, summaries, lots more.

My suspicion is that if the Ape gives a server implementation a clean bill of health, a client written to the spec would be able to use that implementation to create, update, and delete Web resources, and quite likely Just Work.

And by the way, as of the writing of this I’m not aware of any APP server implementations that get green check-marks all the way down the line from the Ape.

How To · You can get the MIT-licensed source at (just because it’s on doesn’t mean that it needs to have any actual Java code, y’know), or you can just go to and point the Ape at your server.

To Do · The biggest thing I want to do with the Ape is switch it back to JRuby so I can go back to RelaxNG-validating all the APP docs with Jing. That was incredibly useful at turning up little bits of subtle weirdness in server implementations, and its absence has forced a bunch of ad-hoc checks for this error or that into the source code.

There are some more things I could add, but at the moment, the best source of input is running this against APP server implementations, each one of which seems to reveal new potential gotchas that the Ape should report on.


Comment feed for ongoing:Comments feed

From: John Cowan (Mar 09 2007, at 18:03)

Why not set up a teensy little server that loads the Jing library and accepts documents on a private socket, returning a validity indication? You probably don't even need to make it multithreaded, as most of the cost of running Jing is startup cost.


From: roberthahn (Mar 09 2007, at 18:35)

Out of curiosity, Tim, I poked around the files in the repo, and I'm a bit surprised you didn't use test/unit as a framework for setting up the protocol tester. Did you try that already and found it lacking?


From: Jonno Downes (Mar 09 2007, at 20:42)

There's some interesting pics of apes (with Creative Commons license) at


From: Kim (Mar 10 2007, at 01:03)

Here's another image found by the commons search.


From: Danny (Mar 10 2007, at 02:16)

Hi Tim,

I don't know how useful it might be around APP, but the EARL test vocab came in very handy for automating GRDDL tests, might be worth a look:

the manifest style came from that of the 2004 RDF tests:


author · Dad
colophon · rights
picture of the day
March 09, 2007
· Technology (90 fragments)
· · Atom (91 more)
· · Syndication (67 more)
· · Web (395 more)

By .

The opinions expressed here
are my own, and no other party
necessarily agrees with them.

A full disclosure of my
professional interests is
on the author page.

I’m on Mastodon!