Proposal: rename repo to multicodec-table
vmx opened this issue · 6 comments
"Multicodec" is a really overloaded term. Some people working om multiformats started to refer to "Multicodec code" instead of just "Multicodec" to describe the idea of a global table of codes. Hence I propose renaming this repository to multicodec-table and encourage everyone proving this table in various programming languages also to name it "multicodec-table" and not just "multicodec". Each entry of the table isn't a codec, but a code.
Pinging various folks for feedback: @rvagg @Stebalien @aschmahmann @bumblefudge, but of course everyone else is welcome.
I'm relatively indifferent other than introducing friction for people. As long as existing URLs continue to work then I don't think it would be a problem. I'm just not sure that it will be consistent. I'd want these two to redirect to a new repo:
- https://github.com/multiformats/multicodec/blob/master/table.csv
- https://raw.githubusercontent.com/multiformats/multicodec/master/table.csv
My hunch is that the first one will redirect but the second one may not.
unlike Rod im more supportive than indifferent of the original idea, and will steal this idea in next version of ietf docs, but I share Rod's concern for linkrot. let me dig around in github docs and validate rods hypothesis
If your objective is to:
describe the idea of a global table of codes
It stands to reason that the name you want is multicode table.
codec, with a c, is itself way overloaded and overused term in the PL-tech space.
It stands to reason that the name you want is
multicode table.
That's a really good point, that's even better. What do others think?
Sorry, I have to disagree with "multicode table", that ship has sailed long ago and it exists as "the multicodec table" in a very large memespace. If we were starting from scratch today then that'd be great to add clarity!
Not a blocking disagreement though, if others agree then I won't stand in the way, just noting that that's a difficult to push a rock up.
- https://github.com/multiformats/multicodec/blob/master/table.csv
- https://raw.githubusercontent.com/multiformats/multicodec/master/table.csv
My hunch is that the first one will redirect but the second one may not.
Taking inspiration from this post which tested redirect behavior of milestone/package-release artefacts post-rename, I tested your hunch from a free-tier org of my own by creating repo testing.123, uploading a PNG file, then renaming it to testing.456. this link at the pre-rename path still seems to resolve to this image without an HTTP-code 301 redirect (i.e. my browser's location bar still shows the pre-rename URL, it is not changed to 456). So maybe that's one less side-effect to worry about?
Sidenote: reading between the lines of various threads about redirect behavior, it would appear they store something kind of like symlinks permanently at old org/repo names, rather than do HTTP redirects properly speaking, but that's just a hypothesis.