Re: Atom Protocol Exerciser (Ape) setup notes

Note: I had intended to post the first part of this on his blogDave Johnson's blog as a comment, but it rejected me twice. Apparently I write like a spammer.

That was a lot more complicated that I had expected; makes me wonder if I'm the first person (other than Tim, of course) to deploy the APE.

I deployed it locally a few months ago, while debugging my Atom protocol plugin for Trac. During that time, I wrote up some implementation questions (which Tim graciously answered) and the method I used to run it.

---

Incidentally, lately I was tweaking my particular implementation since Tim Bray had recently updated the APE to be compliant with the latest revision of the specification. My shebang line for go.rb changed from #!/bin/bash /usr/bin/jruby to #!/usr/bin/env jruby. It's still working fine, even if it's still a little slow.

I need to figure out how to fix some of the errors that I get. For instance:

18. ? Client-provided slug 'ape-61911' not used in server-generated URI.

I have no idea how to fix this. When I get a valid Slug header, I use it verbatim:

To server:

GET /trac/atom/wiki/ape-61911 HTTP/1.1\r
Host: localhost\r
Accept: */*\r
\r

Perhaps the following line is confusing the APE:

Location: http://me.malept.com/trac/xmingw/atom/wiki/ape-61911\r

Additionally, apparently my plugin currently has some problems with the new multi-post app:edited test, but so far I think it's something wrong in my code as opposed to being a bug in the APE. I'm going to try to take a look at it tonight.

Ego++

Typically, I'm not one to toot my own horn too much, but I'm rather excited about this. Because of my earlier post, two things happened:

1. The APE was changed to support HTTP status 204 No Content, and
2. the APP draft specification was changed to clarify (via text and examples) that non-200 OK responses for PUT/DELETE were acceptable.

I think it's awesome that I could (somewhat indirectly) influence a standard like that. At the very least, it gives the ol' ego a little boost.

HOWTO run the APE (or any jruby script) via Apache CGI

In my previous post, I was running the APE via the command line because I couldn't figure out how I could run it as a CGI in Apache. I don't really want to run Tomcat just for this, and I've had bad experiences with Tomcat administration both for school and for work (which I guess is basically the same thing at this point). So after a bout of searching the Internets, I had found a post on JRuby on Rails which helped me greatly in configuring it. So, without further ado, here's the relevant apache configuration snippet:

SetEnv JRUBY_HOME /usr/share/jruby[1]
SetEnv JAVA_HOME /usr/lib/jvm/sun-jdk-1.5[1]
# Jing dependencies
SetEnv CLASSPATH ...[2]
AddHandler cgi-script .rb
Options +ExecCGI

Notes:

1. These values are Gentoo-specific. For JAVA_HOME, I used Java 5 as a precaution, because I wouldn't be surprised if it didn't work in version 1.4.x.
2. On Gentoo, they put all of the third-party jars in separate directories so that their java-config utility can manage them all separately for the system and the users. So, the value I had here (which I didn't want to reproduce here because it's way too long) was the result of java-config -d -p jing. You probably don't have to put this line in if jruby can find jing by itself.

For the APE, I had to add #!/bin/bash /usr/bin/jruby to the top of it. For some reason, CGI complains if you leave out the /bin/bash part of it.

trac-atompp progress; APE questions

I'm working on (among other things) finishing up wiki support in my trac-atompp plugin. I'm nearly done, I think. In order to make sure it's "valid", I'm using Tim Bray's APE (albeit from CVS). However, I've got a few questions about some of the errors:

8. ! 53 of 53 entries in Page 1 of Entry collection lack app:date elements.

From the source, it looks like it should actually say app:edited. But, why is it giving an error? According to draft 14, section 10.2, Atom Entry elements in Collection documents SHOULD contain one "app:edited" element, and MUST NOT contain more than one. Perhaps the messages should conform to RFC 2119 instead of lumping in all of the SHOULDs with the MUSTs, or something.

49. ? Can't update new entry with PUT: No Content [Dialog]
50. ! Couldn't delete the entry that was posted: No Content [Dialog]

I don't really understand why HTTP status code 204 (No Content) isn't allowed for either PUT or DELETE, seeing as RFC 2616 says that it is a perfectly valid response for both actions.