4 ms·

What about in a wiki where things can be created or destroyed?

by scoofy 4y ago

Karellen 4y ago
Then it will be uncool. Heinous, even.
- scoofy 4y ago
  So like... wikipedia does? https://en.wikipedia.org/wiki/Uniform_Resource_Identifier https://en.wikipedia.org/wiki/Uniform_Resource_Identifier
themodelplumber 4y ago
Created, not a problem. Destroyed, handle gracefully at different levels, and possibly in different ways across the site depending on editorial policy. Things should generally not just disappear and leave URIs non-functional. Sometimes it does have to happen but those times should be true exceptions.
- scoofy 4y ago
  I mean, that's all fine and good, but how does one have a descriptive uri, while also having it unchanged? Wikipedia has descriptive URI's, presumably they change over time. I know some folks would prefer never breakage to anything else, but it seems like having a permanent URI with a UUID and a descriptive URI that could change over time, if, say, a building changes it's name: https://en.wikipedia.org/wiki/Willis_Tower https://en.wikipedia.org/wiki/Willis_Tower https://en.wikipedia.org/wiki/Sears_Tower https://en.wikipedia.org/wiki/Sears_Tower One now redirects. I feel like, yea, it's cool if your URI's never change, but as someone building a wiki, it's really always seemed a problem without a right answer. I'm honestly asking because the only way I know how to build my site with this feature is to just save the previous uri every time the descriptive once changes.
  - themodelplumber 4y ago
    Ah, so what you have is a problem that's more special than you can briefly describe for readers here. :-) That's interesting to me, as a topic. Some don't mind having that kind of problem, because it opens a door through which they can gesture at a veritable treasury of details. Details are interesting and very important to them. Perhaps they are even somehow the master of those particular details, for having considered them! Ah ha, great. Others hate it, because they feel like they are springing an unfair trap on innocent passers-by who suggest a simple solution to what seems like a simple problem. I can't say I can solve your problem, and for one it seems different now than it did before, in significant ways. But having walked into it, I can tell you I know this kind of situation! I hope you enjoy puzzling it out, whether through others' ideas or your own well-calibrated wiki-developer brain.
  - PeterisP 4y ago
    Redirects is fine. "Cool URIs don't change" refers to the fact that this resource should be reachable on that URI forever, which a redirect solves; changing URIs without keeping the old URI is what many people do and that's not that nice.
layer8 4y ago
If you genuinely want to make content unavailable, feel free too do that. The article isn’t really about that. Wikis typically keep a history, so they can show a “this topic has been removed” page that still lets you access the history. Or if the topic was merely moved, trigger a redirect. A redirect is perfectly fine, it means that links using the old URL continue to work.
Aachen 4y ago
Use a permalink. I learned this the hard way when Wikipedia was updated to include some (iirc) dumb password advice (or maybe it was about hashing) and I nearly included that in a customer report because my snippet from a previous report used the normal en.wikipedia.org/whatever form instead of en.wikipedia.org/whatever?oldid=123. Wish they wouldn't call it old ID: the latest revision is also referred to as such, and this just looks silly, like why is my consultant linking to a stale ID? Call it page revision or just ID or something... this discourages use of them but it's a core feature. Also, Github links that die all. the. damn. time. Please use the permalink option when copying a file link: this will include the commit hash in the URL and so the link will also work if the file was moved, branch renamed, contents changed, etc.
- scoofy 4y ago
  I guess I don't find: "just use a permalink" without a weighing the pros and cons. I guess I weirdly find descriptive links valuable. I could easily do both, but I think just recording old links is probably an option in the long run. I just think people should be able to click on a URL and know where they're probably going. This still doesn't explain what to do when DB entries are destroyed.
  - Aachen 4y ago
    Neither of the examples I gave obfuscate links when making permalinks. https://de.m.wikipedia.org/w/?title=Valheim&oldid=231146307 https://de.m.wikipedia.org/w/?title=Valheim&oldid=231146307 page title is still in the link, in addition to the revision ID https://github.com/git/git/blob/d15644fe0226af7ffc874572d968598564a230dd/block-sha1/sha1.c https://github.com/git/git/blob/d15644fe0226af7ffc874572d968... also says exactly where you're going, it just replaces the branch master or whatever with the commit. You still see the repository and file path. Permalinks don't have to be obfuscated. The downside I would rather mention is that the link doesn't update to newer revisions if improvements are made. It's not like an LTS version where fixes are still applied but no changes (I guess because every change is supposed to be an improvement to the topic, but yeah, not always).
    - 4y ago

What about in a wiki where things can be created or destroyed?

by scoofy 4y ago

What about in a wiki where things can be created or destroyed?

Karellen 4y ago

Then it will be uncool. Heinous, even.

scoofy 4y ago
So like... wikipedia does? https://en.wikipedia.org/wiki/Uniform_Resource_Identifier https://en.wikipedia.org/wiki/Uniform_Resource_Identifier

themodelplumber 4y ago

Created, not a problem. Destroyed, handle gracefully at different levels, and possibly in different ways across the site depending on editorial policy. Things should generally not just disappear and leave URIs non-functional. Sometimes it does have to happen but those times should be true exceptions.

scoofy 4y ago
I mean, that's all fine and good, but how does one have a descriptive uri, while also having it unchanged? Wikipedia has descriptive URI's, presumably they change over time. I know some folks would prefer never breakage to anything else, but it seems like having a permanent URI with a UUID and a descriptive URI that could change over time, if, say, a building changes it's name: https://en.wikipedia.org/wiki/Willis_Tower https://en.wikipedia.org/wiki/Willis_Tower https://en.wikipedia.org/wiki/Sears_Tower https://en.wikipedia.org/wiki/Sears_Tower One now redirects. I feel like, yea, it's cool if your URI's never change, but as someone building a wiki, it's really always seemed a problem without a right answer. I'm honestly asking because the only way I know how to build my site with this feature is to just save the previous uri every time the descriptive once changes.
- themodelplumber 4y ago
  Ah, so what you have is a problem that's more special than you can briefly describe for readers here. :-) That's interesting to me, as a topic. Some don't mind having that kind of problem, because it opens a door through which they can gesture at a veritable treasury of details. Details are interesting and very important to them. Perhaps they are even somehow the master of those particular details, for having considered them! Ah ha, great. Others hate it, because they feel like they are springing an unfair trap on innocent passers-by who suggest a simple solution to what seems like a simple problem. I can't say I can solve your problem, and for one it seems different now than it did before, in significant ways. But having walked into it, I can tell you I know this kind of situation! I hope you enjoy puzzling it out, whether through others' ideas or your own well-calibrated wiki-developer brain.
- PeterisP 4y ago
  Redirects is fine. "Cool URIs don't change" refers to the fact that this resource should be reachable on that URI forever, which a redirect solves; changing URIs without keeping the old URI is what many people do and that's not that nice.

layer8 4y ago

If you genuinely want to make content unavailable, feel free too do that. The article isn’t really about that. Wikis typically keep a history, so they can show a “this topic has been removed” page that still lets you access the history. Or if the topic was merely moved, trigger a redirect. A redirect is perfectly fine, it means that links using the old URL continue to work.

Aachen 4y ago

Use a permalink. I learned this the hard way when Wikipedia was updated to include some (iirc) dumb password advice (or maybe it was about hashing) and I nearly included that in a customer report because my snippet from a previous report used the normal en.wikipedia.org/whatever form instead of en.wikipedia.org/whatever?oldid=123. Wish they wouldn't call it old ID: the latest revision is also referred to as such, and this just looks silly, like why is my consultant linking to a stale ID? Call it page revision or just ID or something... this discourages use of them but it's a core feature. Also, Github links that die all. the. damn. time. Please use the permalink option when copying a file link: this will include the commit hash in the URL and so the link will also work if the file was moved, branch renamed, contents changed, etc.

scoofy 4y ago
I guess I don't find: "just use a permalink" without a weighing the pros and cons. I guess I weirdly find descriptive links valuable. I could easily do both, but I think just recording old links is probably an option in the long run. I just think people should be able to click on a URL and know where they're probably going. This still doesn't explain what to do when DB entries are destroyed.
- Aachen 4y ago
  Neither of the examples I gave obfuscate links when making permalinks. https://de.m.wikipedia.org/w/?title=Valheim&oldid=231146307 https://de.m.wikipedia.org/w/?title=Valheim&oldid=231146307 page title is still in the link, in addition to the revision ID https://github.com/git/git/blob/d15644fe0226af7ffc874572d968598564a230dd/block-sha1/sha1.c https://github.com/git/git/blob/d15644fe0226af7ffc874572d968... also says exactly where you're going, it just replaces the branch master or whatever with the commit. You still see the repository and file path. Permalinks don't have to be obfuscated. The downside I would rather mention is that the link doesn't update to newer revisions if improvements are made. It's not like an LTS version where fixes are still applied but no changes (I guess because every change is supposed to be an improvement to the topic, but yeah, not always).
  - 4y ago