Glyph Lefkowitz wrote:
with a status code (CONNECTION_REFUSED, NO_SUCH_HOSTNAME) or something when the connection fails. Protocol.connectionFailed goes bye-bye.
The error may be fine as a string instead of a status code - depends on the requirements.
In addition, Itamar's proposal would simultaneously eliminate the confusion currently surrounding Connectors, too; having a wrapper protocol *factory* would not pose the same efficiency concerns as a wrapper Protocol instance, since indirection would only happen when opening and closing the connection.
You still need to deal with connectionLost, which is in the Protocol still. But, if all Protocols have a factory, we could have them report to their factory that they are closed as part of their interface definition. But note that currently we do *not* require that protocols refer to a factory - it's merely a common implementation. Some protocols only refer to their service (e.g. in words, IIRC).
Also, being able to report these errors is important to judge at what level networking is misconfigured for the end-user, when they can't connect.
Well, for servers, just logging errors when attempting to listen on a port it, as we do now is acceptable - most servers work this way, where errors are logged. It's connections that really need error reporting, for clients. Of course, some client applications (p2p, FTP) listen on ports as well...