Generic IAddress connect and listen methods.

[rwall]

It would be useful to have a convenient way of calling appropriate reactor.connect/listen methods based on an IAddress implementation.

Kind of related to #1442.

[rwall]

A simple example of usage.

[rwall]

A updated diff requires reactor to be passed as an argument and without redefining backlog default value; plus an SSL option, thanks to exarkun and tv for ideas.

[rwall]

I've updated my original diff to accept the reactor as an argument and to not override the default backlog argument defined in reactor.listen*

exarkun - you suggested that backlog should be passed as an optional argument to IAddress.init, but I can't see what's wrong with having it as an argument of "listen"

Also, are you sure it wouldn't be better to have connect and listen in a separate class like in dreid's endpoint branch. Just without the adaption, CallableFactory, or WrappingProtocol stuff. Perhaps instead have eg IPv4Address.buildEndpoint(sslContextFactory).connect()

Finally

[dreid]

Replying to rwall:

I've updated my original diff to accept the reactor as an argument and to not override the default backlog argument defined in reactor.listen* exarkun - you suggested that backlog should be passed as an optional argument to IAddress.init, but I can't see what's wrong with having it as an argument of "listen" Also, are you sure it wouldn't be better to have connect and listen in a separate class like in dreid's endpoint branch. Just without the adaption, CallableFactory, or WrappingProtocol stuff. Perhaps instead have eg IPv4Address.buildEndpoint(sslContextFactory).connect() Finally

A large reason why it was ever in a seperate class was my attempt to get rid of Factories as an interface and instead shift them to where I feel they belong, which is as a pattern. I've found that more often than not it is unnecessary to have a factory when working with clients, the endpoints branch also removed them from the server side purely for symetry. One thing you definitely need to do is make the tests clean up after themselves though. Having connect and listen on the IAddress is still really useful.

Regarding backlog: the beauty of endpoints is that every IAddress implementation can provide the exact same interface .listen(factory) .connect(factory) any other arguments given to the respective reactor calls should be instance variables on the object. backlog is one of these, as would be the sslContextFactory. (which is why there is essentially an IClientEndpoint and IServerEndpoint implementation for every reactor.listen and reactor.connect pair, and SSL is distinct from TCP.) Another reason the endpoints don't map directly to an IAddress is demonstrated by UDP vs TCP vs SSL. They all expect the same IAddress implementation, but their connect and listen methods require different configuration such as the sslContextFactory. So i think the most useful course of action would be to keep the IClientEndpoint and IServerEndpoint interfaces, but remove the attempt at getting rid of Factories.

[exarkun]

I think that this is more than related to #1442, it's actually a duplicate of #1442. The point of each ticket is the same: create APIs for clients and servers which are orthogonal to the actual transport being used.