<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jun 12, 2011, at 9:22 AM, <a href="mailto:exarkun@twistedmatrix.com">exarkun@twistedmatrix.com</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: 'Bitstream Vera Sans Mono'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; ">If you want the listen address to be configurable via some configuration<span class="Apple-converted-space"> </span><br>file, or perhaps even in a GUI,<span class="Apple-converted-space"> </span><br>`twisted.internet.endpoints.serverFromString` is one way you might get<span class="Apple-converted-space"> </span><br>this endpoint (in particular, I would emphasize that serverFromString is<span class="Apple-converted-space"> </span><br>really only meant to construct an endpoint if you *have* to start with a<span class="Apple-converted-space"> </span><br>string - as you do when you are reading a configuration file).<br></span></span></blockquote></div><br><div>I think this undersells the string-based API somewhat.</div><div><br></div><div>Generally, you <i>should</i> 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.</div><div><br></div><div>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</div><div><br></div><div> StreamServerEndpointService(TCP4ServerEndpoint(reactor, myPortNumber), someFactory)<br></div><div><br></div><div>to</div><div><br></div><div> strports.service("tcp:%d" % (myPortNumber,), someFactory)</div><div><br></div><div>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).</div><div><br></div><div>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.)</div><div><br></div><div>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 <i>whole</i> 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.</div><div><br></div></body></html>