Repository navigation
Standardize ready event for built-in streams #19304
Description
Activity
I've seen
'ready'used in third party modules (including my own -- although not on core objects directly), so you might be careful about using the event name in case someone is emitting it for their own signalling on TCP sockets for example.@mscdex Do you have any suggestions? Should we just try it, see if something breaks, and otherwise rename?
@ryzokuken It would mean adding the event in the places where the other events are currently being emitted. I think renaming them, including removing the old names, would be too much of a breaking change.
- Agreed. Emitting an extra event sounds like a much safer approach.…On Tue 13 Mar, 2018, 2:32 AM Anna Henningsen, ***@***.***> wrote: @mscdex <https://github.com/mscdex> Do you have any suggestions? Should we just try it, see if something breaks, and otherwise rename? @ryzokuken <https://github.com/ryzokuken> It would mean adding the event in the places where the other events are currently being emitted. I think renaming them, including removing the old names, would be too much of a breaking change. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19304 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMg3MvTa5br9BW0JHxLjDBz8h_GHaTQzks5tduJigaJpZM4SnOfl> .
I'm not 100% convinced this kind of change is really needed though.
It’s going to be helpful in merging streams code between the different implementations.
Actually, it would also be nice to have something like the corresponding boolean property, which is
.connectingfor Sockets and.pendingfor http2 streams, available for all of these consistently.I think the term
'ready'can be misleading and can depend on the object emitting the event.For example, if you make a TLS connection, what does "ready" mean? That the underlying TCP connection was established or that the TLS handshake completed successfully? Do we then have to still have distinguishing events, like
'ready'and'secureReady'? Do we change how TLS sockets work so they no longer emit'connect'but only'ready'once the handshake completes (but "plain" TCP connections will emit'ready')?I just don't see the value in potentially adding more confusion by using a subjective term in core (I haven't paid attention to http/2 support, but I am surprised it is currently using such an event name).
I think the term
'ready'can be misleading and can depend on the object emitting the event.We can bikeshed over the name.
streamReadyworks for me too, but I don’t think the name chosen forhttp2is inapt. edit: orstreamEstablished?That the underlying TCP connection was established or that the TLS handshake completed successfully?
The latter.
Do we then have to still have distinguishing events, like
'ready'and'secureReady'?No.
Do we change how TLS sockets work so they no longer emit
'connect'but only'ready'once the handshake completes (but "plain" TCP connections will emit'ready')?No.
I just don't see the value in potentially adding more confusion by using a subjective term in core (I haven't paid attention to http/2 support, but I am surprised it is currently using such an event name).
You are conflating two things here: The naming of the event (which can be subjective, granted) and whether we should have a single, consistent event name used for these streams.
As mentioned above, I’m okay with another name; the semantics are “this is the point from where reading and writing data actually works”. I think
readywould describe that, but I’d also be completely fine with a more verbose name. (I think we can just change the name on the http/2 stream class if we wanted to.)I do see value in having a single, consistent event name: Partly because it makes our APIs more consistent, which seems like an inherently good thing to me, but mostly because it would actually simplify re-using code between these implementations. (I opened this issue specifically because of that.)
4 remaining items
@addaleax Anna,
I have opened a PR for this. Would appreciate if you can take a look and provide feedback.
Included tests as well.- added 4 commits that reference this issue
on Mar 21, 2018 - added a commit that references this issue
on Mar 30, 2018 - added a commit that references this issue
on Aug 16, 2018 - added a commit that references this issue
on Jul 27, 2026
Currently, various internal streams have different events that indicate that the underlying resource has successfully been established:
fsstreams use theopenevent once the file descriptor is availablenet.Sockets use theconnectevent once the socket has been establishedHttp2Streams use thereadyevent once the underlying http/2 session is establishedI would like to suggest standardizing on emitting
readyfor all of these streams, i.e. emittingreadyforfsstreams and network sockets in addition to the event names they currently use.If there are no objections, I think this makes for a good first contribution.