Ticket #1549 (closed enhancement: wontfix)
[super] Short link tool
Reported by: | ross | Owned by: | |
---|---|---|---|
Priority: | awaiting triage | Milestone: | ckan-backlog |
Component: | ckan | Keywords: | shortlink |
Cc: | Repository: | ckan | |
Theme: | none |
Description
It would be great to have a CKAN extension that allowed users (or CKAN itself) to generate short links to other URIs (both internal and external). Once created, shortlinks made by CKAN should be changeable. This would allow uploaded content to be moved without the user's link changing at all. The tool itself might also be of use as a general link-shortener to users other than the CKAN system itself.
Another useful feature would be for this to also collect some simple analytics such as the referrer and client IP for future reference. I'm not yet sure what we would do with the analytics other than some sort of popularity metric.
Questions:
- Core, or Extension, or Self-hosted?
Change History
comment:2 Changed 2 years ago by ross
Comment from John Erickson (on ckan-discuss):
FYI, such ability to maintain an identifier was an original motivation/requirement of the DOI (which is why the Handle System was the obvious choice for implementation).
Note that providing the ability to maintain the short URL implies some kind of authority --- either based on the originating user or a ckan administrator.
The idea of analytics as a motivator is very good; this is a great feature of bit.ly
Another feature to consider might be short URL lookup based on target URL at short URL creation time, to avoid multiple short URL for the same target.
comment:3 Changed 2 years ago by rgrp
- Status changed from new to closed
- Resolution set to wontfix
Closing as wontfix. Originally needed in context of storage but agreed this is no longer needed there. For general usage don't see the point as twitter etc already have shortlink systems and we have no urgent need for one. Happy for someone to reopen if they feel strongly the other way.
I see a need for short links to any package or resource, so people can Twitter about them.
As far as providing forwarding to a resource URL, even if that changes, then I'm not sure there is a need for it to be short - we could just use a long link with the resource-id. e.g. thedatahub.org/resource/c1e89abb-13cd-4e18-9078-03d15bf6f256/url-forward.