CMS software needs to use useful URLs and it needs to be the easiest thing in the world to drop in an existing set of content into a new CMS and retain the old URLs or transparently redirect them to new ones.

This can be done at the HTTP server level (with Apache URL rewriting for example) but you have to go in and edit config files; you can’t easily do it in a blog or CMS web-based control panel.

It’s hilarious to watch search engines try to make sense of this.

Google:

Did you mean: SaLam Khobi Hogbin Hamilton Nokair TaK Be Taken?

Live:

Other searches you may want to try:

* Take Off Shift Knob
* Hampton Inn
* Hampton University
* Hampton Bay
* Hampton Lakes
* Hampton VA
* Hampton Virginia
* Hampton Beach

A9:

Do you mean salad knob? khogbin? hampton? nokie? take? take on?

in all, its actually a rather good case for virtualization: just create an os images for each webapps so as to allow the image to be easily and rapidly migrated between systems. it insures absolute OS compatibility wherver the server is moved to. with virtualization, its very low impact bordering free to keep a prehistoric mostly unused webserver online, spooling out sporadic responses for antiquated content requests.

VMware has rapidly shifted to providing exactly this type of product. i’ve always associated them with a company focused on creating developer tools and serving niches of people who for whatever reason need multiple os’s, but they’re recently retargetted towards providing deployable os’s to counter these migration woes. its certainly a little odd and perhaps extreme, web technology moving so fast that sites will just go black for lack of supported and compatible runtimes that the solution is to make the entire os deployable, but since web deployment *is* such a huge can of worms and so problematic, its a rather ingenious solution.

imho, urls should always be permenant. engineer room to grow from the start, and ensure old systems remain online or that new systems will be back-compatible. and create and maintain your personal systems with the complete expectation of persistence.

Hanzoweb – http://www.hanzoweb.com – is a web archiving tool with which individuals and institutions can collect pages, sites and blogs via a bookmarklet in their browser, via feeds or a WordPress plugin. The plugin is open source and still a little underdeveloped, but a promising tool in this context. As Hanzoweb is archiving the public web, the crawlers obey robots.txt, so we don’t necessarily get everything a user requests, but what we do collect is stored in our archive using the same archive containers as Internet Archive. Furthermore we have an agreement with Internet Archive to donate our archive to them regularly, to ensure material we collect is safe for a very long time. Hanzoweb provides __real persistence__ for websites and blogs.

DOI and Handles systems are identifiers or naming schemes AFAIR and are used to point to URLs on the live web. These can equally be used to point to archived material in our archive or that of the Internet Archive as both are accessible on the live web too. More important is that several archives, including Hanzo, are working on ideas for federated archive access; the combination of archives and libraries together with federated archive access will ultimately lead to a persistent blogosphere, but not DOI or Handles, certainly not in isolation.

Hanzo also sell a solution for Intranet archiving, which organisations can use to archive internal resources for compliance or other reasons.

Here’s an example of persistence for you Jon: http://www.hanzoweb.com/search/?search=udell

BTW, as I know you’re a fan of Amazon’s S3 and EC2, you might like to know the whole Hanzoweb app is hosted on EC2 and the archive is stored on S3.

[note: I've been a primary developer on the handle system since about 1998]

Because it is an extra step in the “getting to what you want” stage it can seem like a one-more-thing-to-break type of scenario, but it doesn’t have to be. The handle system was designed to be ultra-scalable and reliable in that object identifiers are replicated across multiple servers (similar to DNS, but faster and more flexible) and handle clients talk to each server in the service until they get an answer.

DOI resolution is done using the handle system, but DOI is larger than that – it is a community in which everyone has a stake in making sure the identifiers continue to work and are useful to everyone involved. The handle servers running the DOI system are replicated over a number of sites and are generally very reliable. The only weak spot in the system is the proxy – http://dx.doi.org/ – but even that is load-balanced over a number of geographically separated servers so that the weakness comes down to HTTP itself, and the fact that if an HTTP client can’t get through to one host it will stop trying. Native handle resolvers do not have that problem.

The DSpace use of handles on the other hand does not use any mirroring or failover of its handle servers so there can be errors if a client can’t get to the single DSpace handle server that is responsible for a certain namespace. This is something I’ve been meaning to fix for a while since DSpace is open source. However it is a temporary problem – not a problem that is inherent in the system as is the case with straight up HTTP services.

Because it multiplies moving parts?

Would you then say that the infrastructure and governance aspects of these efforts might just as well play out on the plain old web?