Feature Proposal: Permanent links to topics, that work even if a topic is moved or renamed

Motivation

At work, we have database that contains links to topics in the wiki. If we move or rename topics, it is a pain to have to check and fix the links in the database.

Description and Documentation

Foswiki should provide a link to a topic, that always resolves, even if the topic is moved or renamed. This probably requires that Foswiki should be able to create a unique ID for each topic.

This should probably also affect topic deletion. If a topic is deleted, and it is referenced from elsewhere, then Foswiki should warn that the topic is referenced from outside of Foswiki.The "externally referenced" state should be stored in the topic metadata.

It would be useful if Foswiki provided a rest handler that returns metadata for the topic, given the universal ID. This could include the current URL for the topic, modification time etc. (Such a rest handler may already exist - I don't know if it does).

Foswiki could mark the topic as externally referenced when this rest handler is invoked, and store this information in the topic metadata. The point is to note that the topic is referenced from outside of Foswiki, not necessarily to store all of the external references.

-- MichaelTempest - 11 May 2009

Examples

Example 1:

• Someone creates a topic describing EditorBugs and links to it from outside the wiki.
• Later, someone else sees that the problem is really EditorDoesNotObeyBackspaceProperly and renames the topic accordingly. The external link to the topic should resolve to EditorDoesNotObeyBackspaceProperly. (A redirect from EditorBugs to EditorDoesNotObeyBackspaceProperly would do this.)
• Later still, someone creates a summary topic of all the bugs in the editor. The appropriate name is EditorBugs. It should be possible to create a new topic with the same name as the original topic and not break the permanent link to the original topic. (This would cause a problem with a redirect approach)

Example 2:

• Someone creates ThisProject.DetailedDesign.
• But it should have been ThatProject.DetailedDesign.
• After moving ThisProject.DetailedDesign to ThatProject.DetailedDesign, it should still be possible to create a new ThisProject.DetailedDesign, without breaking permanent links to what is now ThatProject.DetailedDesign.

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: MichaelTempest, OliverKrueger, OlivierRaginel - 11 May 2009

Discussion

11 May 2009:

[16:13]   <OliverKrueger>   MTempest: you want to store all external urls that reference to a topic?
[16:14]   <MTempest>   No - just the fact that it is referenced.
   <OliverKrueger>   Over time, all the booleans will be set to yes.
[16:15]   <Babar>   you know there is a really easy way to solve your current problem?
   <OliverKrueger>   Maybe an inference counter would be more useful.
[16:16]   <MTempest>   In my case - at most 10% of them would be set to yes. And that is assuming that people take the trouble to link to the wiki
[16:17]   <MTempest>   Babar: How?
   <OliverKrueger>   Do your external sources actively/automatically update this boolean?
[16:18]   <OliverKrueger>   but, well,... its just a detail.
   <Babar>   MTempest: add a handler on rename that creates the old topic with a redirect to the new one, using RedirectPlugin or something similar
   * Babar   saw that somewhere, but can't find it back right now
[16:23]   <MTempest>   I expect the uid to be something like an MD5 hash, but I would like sensible names in the database UI, so why not let the database ask Foswiki what the "pretty" name is

Babar's suggestion of a redirect topic would work for many cases. However, it could potentially litter the wiki with "redirect" topics.

The "redirect" approach does not work if the original topic name may be reused.

Discussion

We had that discussion some time ago creating a PermalinkPlugin. Not sure what happened to that brainstorming.

Basically, a redirect approach works out quite well if you do not use web.topic urls for external references. Instead a special permalink is use that has got some unique page identifier. The PermalinkPlugin would then track every move of the topic and update an internal database where to redirect to if that page gets called via permalink.

-- MichaelDaum - 11 May 2009

I did a quick google, it yielded this:

• http://twiki.org/cgi-bin/view/Codev/FrozenLinks
• Discussion on IRC

When	Who	Said what
2006-03-08	Soronthar	bitca: Do you feel like writing a PermaLinkPlugin?
2006-04-09	Soronthar	I really, really hate the concept of CoolURIsDontChange (in a wiki context, i mean)
	Drusilla	Especially when it's used to justify fossilization
	Soronthar	Anyone for a quick idea for a PermalinkPlugin?
	Drusilla	Only thing I've come up with is something vaguely like TinyURL
	Soronthar	good enough a small skin modification to allow the permalink to be shown someplace, et voila Did I mention before that I think that we need a TWikiOrgSkin?
	Drusilla	Don't forget that it has to adjust to moved topics. Or not. Don't forget to think about it, anyway
2008-10-28	MotoLavr	At web level it would be good with some feature that can define an alias for a web which people can setup so TWiki.something is an alias to whatever we call our system web in future.
	SvenDowideit	Babar, because we are changing so much stuff
	gmc	MotoLavr: i was thinking about implementing something like mediawiki anyway
	SvenDowideit	it would be silly to change more
	MichaelDaum	MotoLavr, how about RewriteRules
	gmc	when you remove a page on mediawiki, the old url is still available and redirects to the new s/remove/rename/
	MichaelDaum	Someone proposed a PermalinkPlugin some tome aggo. Merredith was it.
	MotoLavr	RewriteRules is not good enough. It has to work at Perl level. There is plenty of stuff we all have done that depends on TML containing Web.Topic where Web is TWiki sometimes.
	SvenDowideit	yup, there's alot of her stuff that will get done
	MichaelDaum	don't promiss too much your proposed-for-twiki-5 bucket is rather full already, SvenBo.
	SvenDowideit	grin
	MotoLavr	If we make an alias feature that can alias what today is Main and TWiki we will help a lot of people that hate both names today - and maintaining compatibility.

-- MichaelTempest - 12 May 2009

We're seriously concerned about permalinks at work. In our context (scientific collaboration), a simple GUID access mode would be fine.

Ie.:

• /bin/view/Project/ArticleFoo would have a GUID metadata field whose value might be ABCDEF0123456789....
  • A script could be built to generate GUIDs for all existing topics, using a search to find GUID-less topics and running /bin/rest/GuidHandler/mark (?).
  • Might also run a cron job to report topics lacking GUIDs (hopefully after this implementation stabilizes it wouldn't be needed).
  • Creating a new topic should generate a new GUID.
  • Choice: really long hashes (input: time/date+web/topic name+username+content), or carefully managed sequential GUIDs.
    • Thoughts: It'd be nice to use hashes rather than managing GUIDs carefully (concurrency issues, etc).
    • Thoughts: Perhaps it'd be trivial to allow rest/GuidHandler/view script to deal with hash collisions (multiple topics with same GUID).
• /bin/rest/GuidHandler/view/ABCDEF0123456789...
  • It would just be a wrapper to view script to discover the proper web/topic path from the GUID
  • Could just do a dumb grep through all the topics.
  • Should however maintain a cache to make the lookups faster.
  • Same script that would apply GUIDs to existing topics would populate the cache.
  • Creating/renaming topics should update the cache?
  • Cache miss would initiate a "dumb grep" for the new web/topic path containing queried GUID, update cache when found.
  • rest/GuidHandler/view script would just be a wrapper to the view script; after discovering the proper topic name we hand off to the view script.

This is the simplest and most practical solution I've come up with so far. Revisions of the topics could be addressed by appending the usual URLPARMs to the GUID name (all the URLPARAMs should just be handed off to the view script anyway).

Thoughts?

-- PaulHarvey - 09 Jul 2009

I wasnt aware of this topic (anymore). I implemented the PermLinkPlugin in the meantime. Basic functionality is there, but the code is still beta.

-- OliverKrueger - 09 Jul 2009