Repository navigation
Why is http2 exposed as a property of the http module? #29
Description
Activity
There is an existing
http2module on npm that would conflict if we exposed the new http/2 functionality that way. It is unfortunate but necessary. And yes, hopefully it is temporary until a better solution can be found.Could ask nicely if the author of
h2minds giving up their NPM name. Doesn't seem like there are many downloads. Also,http-2with a hyphen is available.Definite possibility. I'd rather avoid hyphenated names as much as possible. Requesting the
h2package name seems like a good choice.http-2
I expect a significant number of people mistyping that as
http2and wasting time on that in the best case, and gaining some other problems from that in the worst case.@nwgh If http2 gets added to core, would you mind giving up the namespace so the core solution can be be implemented elegantly?
- Definitely works. Thank you!…On Fri, Dec 16, 2016 at 2:56 PM Justin Mandzik ***@***.***> wrote: @jasnell <https://github.com/jasnell> I'm happy to relinquish it, especially for node core! I'm traveling this weekend with limited access to computer, but I'll circle back with you Monday if that works. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAa2eeiHGnqZW6g0nCpQaN10s46zIBuhks5rIxcMgaJpZM4LO67p> .
As much as I think h2 is better than a property tacked onto http, I think h2 might confuse users as it's not clear what h2 means. The core API should demonstrate good API design. I don't think h2 for http2 exactly fits in this regard as it's inconsistent with the http and https module. Would love to hear what @nwgh thinks here.
Hi all. Sorry for the lag, must be that time of year :) Anyway, I'm more than happy to give up the "http2" namespace for core. I definitely think that makes the most sense in all respects. I don't have great access to rename the package on npm right now, but later this week I'll rename to something (once I come up with a reasonable name) as I personally (in my role as a Firefox developer) will continue to depend on what we currently know as "http2", as we use that for integration testing of our http/2 stack.
I also agree with @RobertWHurst that "h2" is a little un-descriptive. While it matches the ALPN token (and is what I normally use with other networking types), it's too easily confused with the h2 HTML tag. Best to be more explicit, in my opinion.
I'll circle back around once I've done the rename to let everyone know the namespace is free.
Reacted by Chris Weber, Eric M. Dantas, Gregory Wild-Smith, zhaoxuan, Stevie Huh, Steven and dnalborczykReacted by Gregory Wild-Smith, Abdullah Diaa, Stevie Huh and StevenYou shouldn't really need us for this. https://www.npmjs.com/policies/disputes is our name dispute policy, and it has instructions on transferring names (tl;dr
npm owner add <new-owner>). Keep in mind that formerly-published versions cannot be published over, and if they've been out long enough, cannot be unpublished. This should not be an issue, as you can simply deprecate it with a message to use the nativenode@8one, but even users on older nodes will see it.Personally, I'd just add a note in the README that
http2is superseded by the native module if you're innode@>=8. You could even add anenginesentry so that it warns only on that.If you want more guidance than this or something actually official (I am not saying this stuff in any official capacity. I'm simply mentioning what options you have), then please email support@npmjs.com so we can handle this with existing processes. I don't see any issues, tho :)
What @zkat said also happens to be the official position of npm, Inc. on this matter.
If node-core adds a new builtin that takes over a name currently used in npm, well, that sucks. We've been there before. Please be very careful about that.
If you want the existing owner to move off the name, follow this: https://www.npmjs.com/policies/disputes
If you want technical guidance about how to make that go smoothly, I'm happy to help out.
Reacted by Robert Hurst and Gregory Wild-Smith6 remaining items
Just my two cents here, but I believe it's better to be consistent with the rest of the core modules.
http/2implies to me that it's a sub component for thehttpmodule which it is not.As for rolling the major. It can't be done as core modules are not versioned in the user's package.json. As for code breakage, I would argue that when a user upgrades their node version a whole major, they are opting into breaking changes and will need to fix old code. This is the same as any major release of node where there are breaking changes. Adding HTTP2 should be a whole release major in itself.
As for code breakage, I would argue that when a user upgrades their node version a whole major, they are opting into breaking changes and will need to fix old code.
The user might not be depending on
httpthemselves -- they might have a dependency three levels deep which is using thehttp2module. Upgrading in situations like this is often nontrivial. It's typically better to avoid breaking changes unless there's a good reason to do so, even in a major release.I'm not saying that we can't use the
http2name -- I'm just saying that we should consider non-breaking alternatives such ashttp/2before we jump to the decision that a breaking change is the only way to go.@not-an-aardvark I agree, minimizing breakage is very important. I would just add that so is consistency. Without it you end up with an ugly system.
http/2seems incorrect. A/in a module name has been a separator of a parent and child namespace.2is not a module name, andhttpis not it's parent.The course of action I think would be best here is that the
http2module gets republished under a new name, for example 'http-2' or something else. The originalhttp2module gets updated with a depreciation warning indicating users to switch tohttp-2. Then months later when Node is released with HTTP2 in core, the bulk of the users of the originalhttp2NPM module will have switched over to the newhttp-2module, and thehttp2namespace will be available.Based on my suggestion above I think the things we would need to know here are:
- When is node with http2 likely to ship?
- How many months before node ships do we need to update the
http2module with a depreciation warning? - What new namespace can we use for @nwgh's handy work to keep it available?
For what it's worth, I think
http/2could be reasonably consistent if we madehttp/1an alias forhttp.httpwould effectively be a namespace for all the corehttplibraries (and it would scale well if there is ever anhttp3, for example).I'm probably gonna sound like a complete tool (since I haven't really followed the API design work being done here), but can't http2 simply be married with the already existing built-in http and https? I'm sure that would be a challenge, but would it be impossible? Both
spdyandhttp2modules on NPM have an API that is in essence very similar to the built-in http module, they "just" add extra API on top of that.The http/2 protocol is fundamentally different from http/1 is so many ways that somehow merging the two would be entirely impractical and, in many cases, impossible.
Reacted by Robert Hurst, isaacs and Sebastiaan DeckersThis really is a bikeshed. Here's what I'd recommend (because of course what this is lacking is Yet Another opinion, ha ha)
- Include HTTP/2 support in core as
require("http").http2, as it currently is. As warts go, it's not a bad one. - Send a PR to the
http2module to do this:var http = require('http'); if (http.http2) return module.exports = http.http2; // else, API-matching userland implementation. It might be a breaking change. That's fine, just bump the major version. - Leave it that way until everyone is using a version of
http2that just exports the core module, and a version of node that includeshttp.http2. At that time, move the core module torequire('http2')and thehttp2author cannpm deprecate http2 "HTTP/2 support is included in Node.js core now, this module is no longer necessary. People who really need to use the userland one can dorequire('http2/'). It may take a few years to get to that point. We at npm, Inc. are happy to provide y'all with version usage numbers and download counts. - Never ever remove
require('http').http2. Leave that there forever. It harms no one, and removing it would be unnecessary user-hostility.
Reacted by Ron Korving, Nikita Skovoroda, Gregory Wild-Smith and Robert HurstReacted by Gregory Wild-Smith- Include HTTP/2 support in core as
@isaacs I see what you're saying here. I'm just unclear why you suggest going the warty road here. Unlike the browser environment node has proper versioning. The trade off here in my opinion is that node ends up looking rather confusing to newcomers. It doesn't seem unreasonable to ask that a node user update their code when they decide to bump the Node version a major release.
Reacted by Sebastiaan Deckers@RobertWHurst It's easy to underestimate the cost of breaking changes in Node.js, because as you say, upgrades are opt-in, so what's a few more changes?
But these changes add up, and they result in creating the impression that Node.js is unstable, unreliable, and chasing newness for its own sake rather than investing in quality and the needs of users. You can argue it's unfair, but the fairness doesn't change the perception.
We want people to upgrade. We should make it as easy as possible to do so, even if that means a slightly more cluttered API surface. And really,
require('http').http2is fine.Reacted by Robert HurstWhy should it be
require('http').http2and notrequire('https').http2Also should nothttp2.createServer()with the same parameters as the https version be how you create a server?At this point, we do not need to nail down what the exact namespace / entry point will be. We will have a reasonable entry point and we will take ecosystem impact into consideration in the process. I really appreciate the current owners of the
h2andhttp2modules being willing to turn those over if necessary but it's too early to say for certain that we'll need them. When the time comes to finalize on that decision, the CTC will reach out and work through whatever issues there may be.So after all, how it will be called? Any docs available? Is it available in nightly build? Any info related to http2 should be added to the main page. It's kinda missing or i wasn't reading carefully...
- Still a work in progress but the current implementation is available through require('http2') in this repo.…On Fri, Feb 3, 2017 at 4:15 AM Beck ***@***.***> wrote: So after all, how it will be called? Any docs available? Is it available in nightly build? Any info related to http2 should be added to the main page. It's kinda missing or i wasn't reading carefully... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAa2eUtOf6b3rUTGWSDWvzeY3AylwZyjks5rYxp5gaJpZM4LO67p> .Reacted by Jack, Douglas Wade, Sindre Sorhus, Gregory Wild-Smith, Steven and Robert Hurst
Closing this as we're going to be going with
require('http2')for the time being.Reacted by StevenReacted by Steven
Hi everyone. I'm just curious why http2 is exposed via
require('http').HTTP2? Is this temporary, or the final API? It seems a bit clunky. I was hoping we'd seerequire('http2').As an aside, this is really cool stuff. Really exciting to see this under development. Thanks for your efforts here. 🍻