Fwd: "serialization" of ListeningPort

2014-07-22 Thread David Stainton
I posted this to the twisted mailing list a few weeks ago... and I
wonder if any Tahoe devs have thoughts about this.
We essentially need this core twisted api change in order for Foolscap
to be fully endpoint agnostic on the server side.
I think what I need to do next is to write some code and post it on a
new twisted trac ticket...

-- Forwarded message --
From: David Stainton 
Date: Thu, Jul 3, 2014 at 8:16 AM
Subject: "serialization" of ListeningPort
To: twisted-pyt...@twistedmatrix.com




Greetings,

I wanted to see what people think of this before attempting to open a
Twisted trac ticket and submitting code patches.

I think Twisted servers need a way to derive a client endpoint
descriptor string from a listeningPort. This approximates an idiom
commonly used in Tahoe-LAFS/Foolscap:

"""
serverEndpoint = serverFromString("tcp:interface=127.0.0.1:0")
listeningPortDeferred = serverEndpoint.listen(myFactory)

def doStuffWithPort(listeningPort):
address = listeningPort.getHost()

myHost = address.host
myPort = address.port
clientEndpointString = "tcp:%s:%s" % (myHost, myPort)

# announce clientEndpointString to various clients
# ...

listeningPortDeferred.addCallback(doStuffWithPort)
"""

In this case the server needs to announce a client endpoint string
to various clients... the server has enough information to construct
the endpoint string after the listening port has been created. However
the construction of the endpoint string is not done in an endpoint
agnostic manner... and this code will therefore break when used with
Unix domain socket endpoints for instance.

One way to accomplish endpoint agnosticism would be to have a global
function called
"getClientEndpointStringFromPort" or something like that. This
function would take an IListeningPort object as it's only argument and
return a client endpoint string which can be used to connect to that very
listening port.

Under the hood it should find a plugin that can
serialize the listening port objects into a client endpoint
string. This plugin can be the same class as the client endpoint
parser, since it has the correct "prefix" attribute with which to
construct the client endpoint string.

I am basically saying that each server endpoint type needs a
small amount of unique code in order to serialize into a client
endpoint descriptor string... because there are various IAddress
implementations with different attributes.

Cheers,

David


signature.asc
Description: PGP signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev


Re: Fwd: "serialization" of ListeningPort

2014-07-29 Thread Daira Hopwood
On 22/07/14 17:25, David Stainton wrote:
> In this case the server needs to announce a client endpoint string
> to various clients... the server has enough information to construct
> the endpoint string after the listening port has been created. However
> the construction of the endpoint string is not done in an endpoint
> agnostic manner... and this code will therefore break when used with
> Unix domain socket endpoints for instance.
> 
> One way to accomplish endpoint agnosticism would be to have a global
> function called
> "getClientEndpointStringFromPort" or something like that. This
> function would take an IListeningPort object as it's only argument and
> return a client endpoint string which can be used to connect to that very
> listening port.

listeningPort.getEndpointDescription() would be a more elegant API, no?
But yes, I agree this would be useful, however the API is spelled.

-- 
Daira Hopwood ⚥



signature.asc
Description: OpenPGP digital signature
___
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev