httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <c...@force-elite.com>
Subject Re: mod_atom
Date Wed, 27 Jun 2007 23:06:24 GMT
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


Mime
View raw message