I think clear rules are still missing on how an arbitrary link is
translated into a WikiName. These should really be tight rules like
you already wrote about MediaWiki:
Hm? I thought I wrote the rules out already... What is missing, to
be exact?
Regarding backwards compatibility, I'd recommend ignoring old special
cases (where existing) in favor of allowing for simple rules for 3.0+.
I thought that's what I said in the proposal :)
The only thing really to wonder about is the english plurals -
setting. There's some annoying magic in ReferenceManager to make
sure that "TestPage" and "TestPages" are considered same objects.
Especially the hidden platform dependencies, which are obviously
existing in the file-based provider up to 2.8 should be eliminated.
These are more or less errors, not really features.
* The simple way: Implement some fallback rules in wiki page lookup in
order not to break existing links. If feasible, the corresponding
code
should be marked as being for this purpose only.
Problem: What if some old link isn't valid any more and therefore
gets permanently redirected by this code? Then, someone creates a
new page whose name is just this old link's name. This would break
the old link without touching it directly.
Could you elaborate on that? The current recommendation to create
links (2.8) is to simply put them inside brackets. For example,
[This is a page] creates a link to a wikipage called "This is a
page". In 2.4 and previously, this would actually create a link to
"ThisIsAPage".
Our current implementation checks first for the existence of "This is
a page", and then for backwards compatibility reasons,
"ThisIsAPage". However, internally, these pages are not considered
the same, so it is possible to create "This is a page" even when
"ThisIsAPage" exists, and the new page will then take precedence.
Because *most* of the links at jspwiki.org are these backwards
compatible forms, I don't think we can throw it away. However, what
we can do is to make it a configuration item.
* If the simple way isn't feasible, implement a migration tool which
converts the page names and links in existing repositories.
That may be really difficult to do (he said, having just watched one
corporate migration where things were renamed automatically).
Besides, since it modifies the repository, it needs some pretty heavy-
duty testing.
The export tool can output the names in normalized form, but I'd
hesitate to change the repo contents itself. Besides, it wouldn't
work on most plugins, etc.
/Janne
