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.

Sign up for GitHub

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

Jump to bottom

proposal: x/net/internal/iana: move to x/net/iana #12365

Closed
mdlayher opened this issue Aug 27, 2015 · 3 comments
Closed

proposal: x/net/internal/iana: move to x/net/iana #12365

mdlayher opened this issue Aug 27, 2015 · 3 comments
Labels
FrozenDueToAge Proposal
Milestone
Proposal

Comments

@mdlayher
Copy link
Member

The package golang.org/x/net/internal/iana contains many useful constants which could be very helpful for users outside of the x/net repository.

For example, if I wanted to implement my own IPv4 marshaling and unmarshaling package, I would have to write out a list by hand, or copy the entire list of protocol number constants from the x/net/internal/iana package anyway.

Is there a strong argument for this package to remain internal? Moving it to x/net/iana or similar would provide a great deal of value for a much larger number of users. Because there cannot be external users of this package as-is, the change would only require updating import paths within the x/net packages.

/cc @dominikh
@minux
Copy link
Member

minux commented Aug 27, 2015 via email

@mikioh
Copy link
Contributor

mikioh commented Aug 27, 2015

Sorry, I have no opinion about this.

See https://groups.google.com/d/msg/golang-dev/gcYID6KPnXc/Hil2WBZX-7QJ

I think I understand what you wrote, but I don't believe the package design makes sense. The IANA is in charge of LOTS of numbers (http://www.iana.org/protocols). If this package doesn't have all the numbers, then it is not well named. If it does have all the numbers, then I fear it will become unnavigable, perhaps worse even than syscall. Either choice seems like a serious problem.

I think it might make more sense for now just to paste the numbers into the packages that need them, as unexported constants. Three packages is not that many.

@adg adg added Proposal and removed Proposal labels Sep 25, 2015
@rsc rsc added this to the Proposal milestone Oct 24, 2015
@rsc
Copy link
Contributor

rsc commented Oct 24, 2015

No thanks.

As Mikio quoted me saying before:

I don't believe the package design makes sense. The IANA is in charge of LOTS of numbers (http://www.iana.org/protocols). If this package doesn't have all the numbers, then it is not well named. If it does have all the numbers, then I fear it will become unnavigable, perhaps worse even than syscall. Either choice seems like a serious problem.

I also disagree that exposing the current package would "provide a great deal of value" for a significant number of users. And I think we're not set up well to manage the package.

@rsc rsc changed the title proposal: move x/net/internal/iana to x/net/iana proposal: x/net/internal/iana: move to x/net/iana Oct 24, 2015
@rsc rsc closed this as completed Nov 2, 2015
@golang golang locked and limited conversation to collaborators Nov 4, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge Proposal
Projects
None yet
Milestone
Proposal
Development

No branches or pull requests
6 participants
@mikioh @rsc @minux @mdlayher @adg @gopherbot