[Telepathy] File transfer spec: need for advice

[Simon McVittie]

Sorry we've been blocking your work by being slow to respond to this -
OLPC deadlines meant we had to focus on getting Tubes right as quickly
as possible, so I didn't have time to explain the interaction with file
transfer that I'd intended.

On Wed, 05 Sep 2007 at 12:00:08 +0200, Marco Barisione wrote:
> Now we have the tubes spec, what should I do for file transfer?
> Currently in the ft spec we have only non-abstract Unix sockets, do we
> need to support other socket type? IMO Unix sockets (both abstract and
> non-abstract) are enough, later we can add Windows named pipes.

The spec should include support for any socket type supported by Tubes,
I think (with all the introspection stuff that goes with it). It'd be
fine for your implementation to only support non-abstract Unix sockets, though.

> To support multiple socket types we can add
> GetAvailable(Stream)?FileTransferTypes () -> a{uau}

The word Stream is unnecessary here. I for one don't want to transfer
files over anything that's not a reliable, ordered stream :-)

The reason we explicitly say "Stream" in the Tubes method names is that
we have two tube types, D-Bus and Stream (TCP-ish), and we plan to add
Datagram tubes (UDP-ish) at some point. We plan to use the stream
tubes' socket address/access control machinery for datagram tubes too.

GetAvailableSocketTypes() would be a shorter name for this - it's
namespaced by the D-Bus interface anyway. The only potential problem
with clashing names from different interfaces is if the same service
needs to implement both - that's tricky in some bindings - but channel
types are mutually exclusive anyway, so it shouldn't be a problem.

> Another option is to be more generic and replace
> GetLocalUnixSocketPath() with a
> Get(Stream)?FileTransferSocketAddress() method, similar to
> GetStreamTubeSocketAddress().

GetFileTransferSocketAddress() sounds like the way forward, although
it'd be nice if the method name was shorter. GetSocketAddress() would be
sufficient, I think.

	Simon