I get what you are saying... but let's back up a second; foolscap (in my branch https://github.com/david415/foolscap/tree/endpoint_descriptors_server2) uses clientFromString and serverFromString to translate twisted endpoint descriptors into endpoint objects... AND foolscap doesn't know any details about how the endpoint wire protocols work... and we'd like to keep it that way. That's really the point of this exercise. The calling party using foolscap... in this case Tahoe-LAFS also doesn't know anything about any wire protocols. It simply receives twisted endpoint descriptors from the user and passes them to foolscap. On Fri, May 2, 2014 at 2:20 PM, Tristan Seligmann <mithrandi@mithrandi.net> wrote:
On 2 May 2014 15:59, David Stainton <dstainton415@gmail.com> wrote:
This will work fine for the txsocksx tor client endpoint parser I wrote... However the txtorcon Tor Hidden Service endpoint setup requires a deferred to fire once the tor process is started... This means that the endpoint parser needs to return a deferred. But this breaks the interface!... meaning that foolscap or any other api using this onion endpoint parser will have to special case the situation where serverFromString returns a deferred.
I think you're approaching this from the wrong angle; instead of starting the tor process during parsing of the endpoint, I think it would make more sense to start the tor process when the endpoint is started. -- mithrandi, i Ainil en-Balandor, a faer Ambar
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python