Would it be possible (and desirable?) to create a application-linkpreserver contrib repository?
Would this interest the XWiki community? I’m not set on the name either and gladly take suggestions for the name or the design presented.
Presentation of the idea
The idea behind this application would be that some people migrate to XWiki from another wiki solution, or from a CMS and want their old links to still work (because Cool URIs Don’t Change). Visitors could have mails linking to the old website, or could have bookmark.
Redirections could be handled from a reverse proxy, but this is not ideal:
it doesn’t scale: we are speaking of one or several links per document (one per action, possibly one per document revision too), which makes for a very large proxy configuration which may also be difficult to generate)
XWiki can have the knowledge of how to resolve the old links thanks to metadata provided by a migration tool, or thanks to document metadata.
For instance, if a link contains the title of a document, we can do our best to find a matching document.
the Confluence migrator can issue ConfluencePageClass objects witch contain the id of the documents in Confluence. Old links containing the document id can be resolved by looking them up
Design
The reverse proxy would be configured to redirect all links from the old wiki (say, beginning with /wiki/) to a particular resource handler (say, /wiki/preservedlinks). A resource handler would then intercept these requests and try to resolve them.
This would be done by providing interfaces to implement converters which would match URLs using regular expressions, a bit like what nginx or apache 2 allow to do with their location blocks. The converters can of course be provided by other extensions, for instance extensions specific to the source wiki / CMS, or even custom converters for specific websites with specific architectures.
The application would allow some things to configured, for instance whether an interstitial page should be shown, how to handle errors, etc.
(the arrows at the bottom only come from the converter in the middle but that’s a drawing simplification, they can come from any (but only one at a time) converter)
If I understand correctly, you are suggesting me to keep this idea, but use the URL API instead of the Resource API to implement it (and it could still be done in a contrib project - i.e. you are not telling me that the URL API is actually what I’m trying to implement, and “Link Preserver” would be some kind of a duplicate of the URL API).
If I understand correctly, it is higher level than the Resource API since it uses it. It allows implementing resolvers that resolve an ExtendedURL to a ResourseReference, and serializers that serialize a ResourceReference to an ExtendedURL, correct? Is there a way to set up redirects with this mechanism, or to implement interstitial pages? Is there a way to say “I want to get all URLs with the given url prefix”? How does one register a URL scheme? Can it be dynamic (e.g. outside the XWiki configuration?)
The Resource API feels like at the right level of abstraction for me, I’m afraid the URL Schemes might be too limiting, but maybe I’m understanding something wrong here.
Yes, the URL API is meant to support several URL schemes and what you were essentially proposing was to implement a dynamic custom URL scheme (dynamic in the sense that the scheme would not be static/hard-coded but based on metadata stored in wiki pages or elsewhere).
The scheme used by XWiki is configurable and your custom scheme could be configured to be used.
Ofc, since the URL API uses the Resource API, you could redo some plumbing, it’s not much additional work.
There’s no redirect need if you implement a custom URL Scheme (as the URL scheme becomes the XWiki scheme). In essence, your implementation just takes an ExtendedURL and decides how to find the EntityReference it is pointing to (and the action and parameters).
Your impl will get ALL XWiki URLs and will need to decide what they represent.
The scheme used by XWiki is set once. So far we’ve not had the need nor the use case to have dynamic schemes (and it doesn’t seem to be your use case either).
While we’ve coded the concept of URL Scheme so that we could have any format of URLs in XWiki, so far, we’ve mostly use the “standard” scheme, so it’s indeed possible that there could be some limitation we haven’t seen yet. OTOH it would be interesting to find out and have a second implementation to validate it fully (we did some partial impl of alternate schemes but not full ones).
I’ll leave it to you to decide what you want to use (you can also ping me to have a verbal discussion if you want). I was just mentioning URL schemes since it seems to me to be your exact use case.
what you were essentially proposing was to implement a dynamic custom URL scheme
exactly
There’s no redirect need if you implement a custom URL Scheme
Here, I’d rather cover the case where we want people to update their old links and be able to unplug the “link preserver” at some point. This seems best done as a redirect to the “standard” url, and optionally with an interstitial screen telling the user to update their bookmark.
But It might actually be possible to do this using a URL Scheme by showing a special document with some query parameter, which will be in charge of doing the redirect. Seems a bit like a hack, but probably okay. It’s not like it’d be fundamentally different by using the Resource API directly anyway.
Your impl will get ALL XWiki URLs and will need to decide what they represent
Ok, that’s the critical part I’ve been missing.
I’ll leave it to you to decide what you want to use (you can also ping me to have a verbal discussion if you want). I was just mentioning URL schemes since it seems to me to be your exact use case.
Thanks the details and the offer! I’ll give the URL scheme a shot, thanks for mentioning it.
