When I designed DWiki back in the mists of time, I decided that itwould not require any writable data store (and certainly not an actualdatabase, because that would have required me to configure and run one);I wanted to be able to run it completely read-only, so I could worryless about its security implications. I also decided that it should nothave explicit metadata embedded in page data, which are all in regulartext files.

Blog entries have one primary time associated with them, their

From a comment on a previous entry :

There is considerable merit in allowing blacklisted sites to contactyou to let you know that you've blacklisted them in error.

I'm not really convinced of this; especially I am not really convincedthat it's at all useful to make it easy to do so from the outside,for example by never blocking email to postmaster. For a start, ifa blocked site contacts me to say 'we are trying to mail your usersbut you are rejecting us'

So you have a website, and you want it to be able to survive aSlashdotting (these days probably as likely to come from Reddit, Digg,or something I'm too out of touch to have heard of as from Slashdotitself). Assuming that you're not going to blow your bandwidth (a saferassumption than it used to be; these days you can usually offloadpictures and videos to someone else), what usually takes sites down inthis situation is your web server getting overloaded with the

I've recently been thinking about what features we need for painlesslong term storage management , and in theprocess I've been thinking about what we actually do here with ourSAN-based NFS fileserver storage over time. Somewhat condensed, we seemto:

• add new storage units.
• replace existing old storage units with new ones, possibly with some consolidation because disk and thus unit capacities keep growingover time (so that it's not a one to one replacement of units).

  (We have relatively undemanding