On Jun 27, 2007, at 12:44 AM, Paul Querna wrote:
In a way, you could view the Atom Publishing Protocol in the same
light
as DAV. In that case, it makes sense to have generic module which
handles the protocol bits of APP, and provides a set of
callbacks/providers for other modules to use.
It dawns on me that I should probably have said a few words about
this subject. The big difference between DAV & the Atom Publishing
Protocol (APP) is that DAV exposes server-side storage with
filesystem-like semantics so clients decide where to put things,
while APP is all about making life easy for dumb clients: "Server,
here are some bits". "OK, client, their address is now http://
whatever ". The protocol bits of APP are almost the null set,
consisting of one extra header "Slug:" and then some additional
semantics added to PUT/POST/DELETE when the server advertises APP
functionality.
As it is currently written, I don't think it makes too much sense
to put
it into httpd -- but if we could work on abstracting down a core,
and a
set of separate hooks for storage + maybe a way to easily build end
user
display, I think it would be a very cool thing to include.
We'll have to think about that. The whole point of APP is so dumb
clients like cellphones and blog-authoring packages can push bits at
a server and leave the server in control of where things go. I'm
trying to imagine what the storage hooks might look like. As for end-
user display, I doubt it; there are all sorts of excellent blogging &
publishing engines out there that take care of that for you and httpd
doesn't need to compete with. APP & mod_atom are narrowly focused at
the problem of resource CRUD.
On the test cases: Have you looked at how the Apache Perl Test
Framework
works? Its well... Perl... But it works pretty well for interacting
with modules and testing over HTTP:
http://svn.apache.org/repos/asf/httpd/test/trunk/perl-framework/
I'll look at that. Fortunately, there are already two OSS test
harnesses specifically for APP, so that made life easier. -Tim
