Fwd: "serialization" of ListeningPort

[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 <dstainton415 at gmail.com>
Date: Thu, Jul 3, 2014 at 8:16 AM
Subject: "serialization" of ListeningPort
To: twisted-python at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 817 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20140722/cd993b00/attachment.pgp>