httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bray <Tim.B...@Sun.COM>
Subject Re: mod_atom
Date Wed, 27 Jun 2007 23:08:53 GMT
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

Mime
View raw message