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
