Frozen Links

Introduction

Meredith raised the spectre of "frozen links" again on IRC the other day. This has been discussed before, but never acted on.

The problem is that CoolURIsDontChange, and TWiki allows you to modify topics, move them around, even delete them. But there is often a case that you want to send a link to a specific version to someone, that would point to that version of the topic irrespective of what happened to the content subsequent to the link being created.

Idea 1: Leaving a trail

TWiki already supports linking to older revs of topics. Basically this idea is that if I have a link to ThisTopic, and someone moves ThisTopic to ThatTopic, a link to ThisTopic should still work even though the topic has moved.

The fact that currently when you move a topic, you also move the history, is actually a bug.

So, WIBNIF when you move ThisTopic to ThatTopic, links to ThisTopic still work, but refer to a read-only copy of the last revision of ThisTopic before it was moved? The same also applies to deleted topics, of course. Moved topics would of course play no part in searches, would not appear in index lists, and could be retired after a time subject to a log of accesses to the moved topic. Frozen copies would also say whether the topic was moved, deleted or whatever, and link to where it was moved to.

Of course, if someone subsequently re-creates ThisTopic with different content, the link cannot be expected to "know" that the link is meant to refer to an "old" version of ThisTopic; but in most cases, including the 'Attic' case under discussion here, it would work rather well.

BTW I say "topic" above, but of course I mean any versioned container i.e. attachments and webs as well.

So, requirements:

1. Any version-controlled resource in TWiki should be movable using TWiki (rename or delete)
2. Version controlled resources are referred to by HTTP links. After a version controlled resource has been moved, HTTP links (TWiki view and viewfile links) to the source location of that resource must continue to generate a read-only copy of the resource content that existed at the time it was moved. (this is referred to as the spoor of the resource)
3. The full format of TWiki resource links need not be supported; however the following features shall be available:
   1. view raw=all
4. Spoor shall not act like active resources; for example, WikiWord and SquareBracketLinks links to spoor topics shall be broken, spoor shall not appear in indices or searches.
5. The spoor should include the complete revision history of the resource.
6. The page(s) rendered for a spoor should include a prominent link to the new location of the resource, where appropriate/possible.
7. If the name of the spoor is subsequently re-used for a new topic, then the spoor shall be lost forever.
8. A cron script will examine spoors and the access logs and delete spoor that has not been referenced for an admin-definable period of time.
9. The creation and deletion of spoor will trigger plugin handlers.
10. An API to access/manipulate spoor will be made available to Plugin/Contrib authors.

If anyone would like to sponsor the work, I would be happy to undertake to provide an implementation using the existing RCS store.

Idea 2: Permalinks

Instead of leaving a trail when a topic is moved, a simpler and complementary approach is to support the idea of a "permafrosted" link. This would be a link to a revision that, once created, could never change, even after the topic has been moved away and subsequently recreated.

This should be doable using a PermalinkPlugin which maintains a database using the afterSaveHandler() that maps the permalink to the current location of the topic registered for it at creation time. So using an url like http://.../bin/permalink/ will not look so nice, but will be permanently usable in any context outside the wiki. If the destination web of a move action is the Trash web then the permalink is removed from the database.

Note that this would give you a link to a specific link in the history. Normal TWiki operations around that rev would not be available.

The plugin could be implemented by requiring that a permafrosted link is explicitly requested. The request process could cause an HTML version of that specific revision of the topic to be archived.

-- Contributors: CrawfordCurrie, MeredithLesly, MichaelDaum

Discussion

I would disprefer a "Move Topic" that is no real move. In fact the problem is that moving a topic is the same as renaming it right now and does not always match the user's intend: "move away " is more likely a "move to trash" or "move to archive" whereas "rename topic" will likely keep the thing in place but only -- let's say -- correct a typo in the topic name or improve the topic name (users have problems naming topics).

What Meredith proposed earlier (correct me if I am wrong) is a way to have any stable urls at all. This is not the Web/Topic url but an url generated automatically. snipped and pasted in idea 2 above

Admitted, the 'Attic' case on twiki.org is a different issue that can not be resolved this way. But I wouldn't refactor the twiki store just because twiki.org has lots of stale content.

If for any reason you need to redirect to the new location of a moved topic then I'd opt for installing the RedirectPlugin and add a stub that does the redirect. But that's not appropriate on a larger scale but more of a one-time script job.

-- MichaelDaum - 08 mar 2006

Stale content isn't just a problem for TWiki.org, it is a common issue affecting any large site.

While the plugin approach will work, I personally think that it would be stunningly inefficient. But it has the considerable attraction of being relatively easy to implement; I look forward with interest to the PermafrostPlugin making its debut.

-- CrawfordCurrie - 08 Mar 2006

The technical term is permalink (not permafrost link) and goes back to Scott Banister and Matt Kerner in 1995. The wikipedia article even has a section about versioning and permalinks.

-- MichaelDaum - 08 Mar 2006

The HTTP protocol has status codes for topics moved both temporarily and permanently. Granted they're too often not honored, let alone acknowledged.

-- FredMorris - 30 Sep 2007