Hi everyone!
As you probably know (because you are maintaining this code) spdy currently makes heavy use of assumptions about Node's internals, and in particular I'm thinking about the whole handle-thing stuff.
Obviously, breaking ecosystem modules like spdy is not a goal for Node, but this still puts Node core maintainers in a situation where it's unreasonable to take special care about not breaking spdy when the rest of the ecosystem, who plays by the rules and relies on public APIs instead, would benefit from changes.
So:
- In the short term, how sure it is that you are willing to keep up with changes happening in Node yourself? I am opening this issue because I'm working on some stuff that does seem to break
spdy; Those would go into a semver-major release on Node's side anyway, and would probably be easy to fix, but who's to say that that's always going to be the case?
- In the long term, what do you need from Node core to avoid this problem altogether? It seems you're using code to create custom
net.Socket instances, but it's not really clear to me why that requires hooking into Node's internals?
Hi everyone!
As you probably know (because you are maintaining this code)
spdycurrently makes heavy use of assumptions about Node's internals, and in particular I'm thinking about the wholehandle-thingstuff.Obviously, breaking ecosystem modules like
spdyis not a goal for Node, but this still puts Node core maintainers in a situation where it's unreasonable to take special care about not breakingspdywhen the rest of the ecosystem, who plays by the rules and relies on public APIs instead, would benefit from changes.So:
spdy; Those would go into asemver-majorrelease on Node's side anyway, and would probably be easy to fix, but who's to say that that's always going to be the case?net.Socketinstances, but it's not really clear to me why that requires hooking into Node's internals?