Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: rename repo to multicodec-table #346

Open
vmx opened this issue Apr 8, 2024 · 6 comments
Open

Proposal: rename repo to multicodec-table #346

vmx opened this issue Apr 8, 2024 · 6 comments

Comments

@vmx
Copy link
Member

vmx commented Apr 8, 2024

"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.

@rvagg
Copy link
Member

rvagg commented Apr 8, 2024

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:

My hunch is that the first one will redirect but the second one may not.

@bumblefudge
Copy link

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

@ribasushi
Copy link

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.

@vmx
Copy link
Member Author

vmx commented Apr 11, 2024

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?

@rvagg
Copy link
Member

rvagg commented Apr 14, 2024

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.

@bumblefudge
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants