id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
243	add listener-endpoint plugins	Brian Warner		"As discussed in https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517#comment:54 , it will help Tahoe if we can add a server-side plugin mechanism to Foolscap.

Once #203 is done, `tub.listenOn()` will be able to accept arbitrary server-endpoint descriptor strings: anything that Twisted's `endpoints.serverFromString()` can handle. This plugin will layer in front of that, so calling `tub.addServerPlugin(""foo"", plugin)` will make a subsequent `tub.listenOn(""foo:stuff"")` call get its endpoint from `plugin.get_endpoint(""foo:stuff"")` instead of `endpoints.serverFromString(""foo:stuff"")`.

If no plugin is registered for the given type, it will always fall back to `endpoints.serverFromString()`. This is different from clients, where unrecognized connection hints are ignored. The security properties for server descriptors are different (they come from the local admin, not the remote FURL provider), so we don't need to prohibit any particular types.

This gives the plugin the opportunity to include additional configuration options when constructing the endpoint. Twisted has a built-in plugin mechanism for installing endpoint-string parsers, but it is global: any extra information (like which Tor daemon to use when allocation a .onion address) would have to be provided in the descriptor string itself. For Tahoe, that's a nuisance, because we must already provide this data elsewhere for client purposes. Without plugins at the Foolscap layer, the Tahoe config would need to duplicate this data in both the client section and the `tub.port` string."	enhancement	closed	major	0.12.0	network	0.7.0	wontfix