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 ape.dev.java.net (just because it’s on java.net doesn’t mean that it needs to have any actual Java code, y’know), or you can just go to www.tbray.org/ape 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.