You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Tim Bray <Ti...@Sun.COM> on 2007/06/27 08:30:13 UTC
mod_atom
Passes lots of tests, but still lots of work to do: written up at
(extreme) length here: http://www.tbray.org/ongoing/When/200x/
2007/06/25/mod_atom
I don't know if httpd needs this mod_atom, but I suspect that it'll
need some mod_atom or another before too long. It would be nice to
be able to POST random bits and have httpd say "OK, got it, here's
where I put them".
-Tim
Re: Testing frameworks [was: mod_atom]
Posted by Issac Goldstand <ma...@beamartyr.net>.
Garrett Rooney wrote:
> On 6/27/07, Issac Goldstand <ma...@beamartyr.net> wrote:
>> Paul, do you know offhand what the difference is between the
>> perl-framework, and perl.apache.org's Apache::Test framework? I'm
>> familiar with the latter, and have found it to be an amazing tool for
>> testing Apache modules written in all languages (and web applications of
>> any sort running on Apache), but don't have any real familiarity with
>> the former...
>
> They're the same thing.
>
> -garrett
Heh. That explains it (though I'll need a crowbar to yank my foot out
of my mouth now ;-))
Issac
Re: Testing frameworks [was: mod_atom]
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 6/27/07, Issac Goldstand <ma...@beamartyr.net> wrote:
> Paul, do you know offhand what the difference is between the
> perl-framework, and perl.apache.org's Apache::Test framework? I'm
> familiar with the latter, and have found it to be an amazing tool for
> testing Apache modules written in all languages (and web applications of
> any sort running on Apache), but don't have any real familiarity with
> the former...
They're the same thing.
-garrett
Re: Testing frameworks [was: mod_atom]
Posted by Issac Goldstand <ma...@beamartyr.net>.
Paul, do you know offhand what the difference is between the
perl-framework, and perl.apache.org's Apache::Test framework? I'm
familiar with the latter, and have found it to be an amazing tool for
testing Apache modules written in all languages (and web applications of
any sort running on Apache), but don't have any real familiarity with
the former...
Issac
Paul Querna wrote:
> 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/
>
> -Paul
>
Re: mod_atom
Posted by Nick Kew <ni...@webthing.com>.
On Wed, 27 Jun 2007 00:44:42 -0700
Paul Querna <ch...@force-elite.com> wrote:
> Tim Bray wrote:
> > Passes lots of tests, but still lots of work to do: written up at
> > (extreme) length here:
> > http://www.tbray.org/ongoing/When/200x/2007/06/25/mod_atom
Nice writeup! The Loneliness of the Geek made me smile
("... the intersection of those two groups is, I suspect, me.")
> > I don't know if httpd needs this mod_atom, but I suspect that it'll
> > need some mod_atom or another before too long. It would be nice to
> > be able to POST random bits and have httpd say "OK, got it, here's
> > where I put them".
I've implemented similar functionality in a quick-hack module using
a homegrown protocol (mod_choices from my book is distilled from
part of that effort). Moving that to a standard protocol like Atom
probably makes a lot of sense. Now I'm going to have to look at
whether your mod_atom provides a good framework for that.
Moral: there could be latent demand within geekdom.
> 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.
At this point we get into a possibly-even-smaller intersection.
If we're looking at mod_dav, we need to look at what it does right,
but also at its weaknesses, so mod_atom can learn from them.
> For example, this is how mod_dav interacts with both mod_dav_fs and
> mod_dav_svn.
>
> 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.
On a purely practical note, dropping it in as a subproject would
improve visibility and get it under version control.
/me puts "look at this" on his todo list.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: mod_atom
Posted by Paul Querna <ch...@force-elite.com>.
Ian Holsman wrote:
> Tim Bray wrote:
>> On Jun 27, 2007, at 12:44 AM, Paul Querna wrote:
>>
>>> 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.
> If I am understand Paul correctly,
>
> what Paul is meaning on the storage side is so I can add a module to say:
>
> "I want these things stored on a file system"
> or add a different one
> "I want these in a database"
> and possibly have a 3rd party developer decide.
> "This is really cool. I want the data to reside in Bigtable"
>
> this decision would be hidden from the user. just as it is hidden from
> the user in the SVN client at the moment.
Yep, thats exactly what I meant.
Yes, it would most of the API calls in APP would be translated nearly
directly into callback functions, but you would for example try to do
all/any of the XML parsing inside the core 'mod_atom', but the decision
on where to store it would be done by mod_atom_sqlite or mod_atom_fs.
-Paul
Re: mod_atom
Posted by Tim Bray <Ti...@Sun.COM>.
On Jun 27, 2007, at 3:33 PM, Ian Holsman wrote:
>> 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.
> If I am understand Paul correctly,
>
> what Paul is meaning on the storage side is so I can add a module
> to say:
>
> "I want these things stored on a file system"
> or add a different one
> "I want these in a database"
> and possibly have a 3rd party developer decide.
> "This is really cool. I want the data to reside in Bigtable"
Hmm. OK. So the "abstract storage" module would have to do the
following:
- given a bag of bits and a media type, store it and generate a URI
to use in retrieving/editing it
- allow it to be replaced by an action keyed on that URI
- provide an iterator function so you can walk through the things
that have been stored in reverse-chronological order.
...I think. Yeah, mod_atom could do that, and the amount of re-
engineering would be tolerable. I'm a bit dubious, because if you
want an Atom store that puts things in a database, there are already
a bunch of those available. For the time being, I'm going to
continue QA & refinement of the file-based back-end, because that
provides a highly functional drop-in Atom store without any extras
required. The best time to design this kind of abstraction is when
someone has a concrete requirement to use it and concrete back-end
store to link to. That way you don't waste time building throw-away
abstractions. -Tim
Re: mod_atom
Posted by Ian Holsman <li...@holsman.net>.
Tim Bray wrote:
> On Jun 27, 2007, at 12:44 AM, Paul Querna wrote:
>
>> 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.
If I am understand Paul correctly,
what Paul is meaning on the storage side is so I can add a module to say:
"I want these things stored on a file system"
or add a different one
"I want these in a database"
and possibly have a 3rd party developer decide.
"This is really cool. I want the data to reside in Bigtable"
this decision would be hidden from the user. just as it is hidden from
the user in the SVN client at the moment.
Regards
Ian
Re: mod_atom
Posted by Tim Bray <Ti...@Sun.COM>.
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
Re: mod_atom
Posted by Paul Querna <ch...@force-elite.com>.
Tim Bray wrote:
> Passes lots of tests, but still lots of work to do: written up at
> (extreme) length here:
> http://www.tbray.org/ongoing/When/200x/2007/06/25/mod_atom
>
> I don't know if httpd needs this mod_atom, but I suspect that it'll need
> some mod_atom or another before too long. It would be nice to be able
> to POST random bits and have httpd say "OK, got it, here's where I put
> them".
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.
For example, this is how mod_dav interacts with both mod_dav_fs and
mod_dav_svn.
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.
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/
-Paul