On Jun 12, 2011, at 9:22 AM, [email protected] wrote:
> If you want the listen address to be configurable via some configuration
> file, or perhaps even in a GUI,
> `twisted.internet.endpoints.serverFromString` is one way you might get
> this endpoint (in particular, I would emphasize that serverFromString is
> really only meant to construct an endpoint if you *have* to start with a
> string - as you do when you are reading a configuration file).
I think this undersells the string-based API somewhat.
Generally, you should start with a string, because that's the most flexible
mechanism available: it leaves the selection of the endpoint type up to the
user, which is what most protocols want to do. It's the only plugin mechanism
that Twisted offers at this point for new endpoint mechanisms. (It might be
even cooler to have a form-based or GUI plugin mechanism as well, but strings
are usually all that we have to go on.) Avoid the impulse to construct
specific endpoint types unless you need to have a specific type.
serverFromString and clientFromString should be the default APIs for most new
applications.
I think that what exarkun was really trying to emphasize here is that, if you
know that your protocol specifically supports TCP and only TCP, you should
prefer
StreamServerEndpointService(TCP4ServerEndpoint(reactor, myPortNumber),
someFactory)
to
strports.service("tcp:%d" % (myPortNumber,), someFactory)
because the former, while it is a bit more verbose, clearly expresses what
you're trying to do, whereas the latter depends on the 'tcp' plugin having a
specific behavior (which, since it's a plugin, might be overridden or changed
in the future).
This problem becomes more pronounced when you're using the 'ssl' endpoint type,
because if you're importing the endpoint you will be able to see a clear
exception if SSL is not available, but if you're relying on the string plugin
system it won't break until you actually try to start listening. (And yet more
pronounced if you were to rely on some endpoint plugin type that isn't provided
with Twisted.)
In other words, you should tend to prefer one of the APIs that accept a string
(strports.service, serverFromString, clientFromString), but if you use such an
API, pass the whole string from the user into that function, so that you pass
the flexibility on to your users and you don't introduce hidden dependencies
into your application.
_______________________________________________
Twisted-Python mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
