[Telepathy] file transfer spec comments

[Robert McQueen]

Hi folks,

I've been reading through the file transfer spec on Merge Monkey at
http://monkey.collabora.co.uk/mirror-spec-filetransfer/ and have a few
comments.

* What's the purpose of the last change reason being kept around in the
list of transfers? Guarding against an incoming offer being cancelled
before the client has launched/responded?

* If the incoming file transfer stuff allows arbitrary incoming handles,
this suggests we might be able to use this channel for receiving file
transfers from members of a multi-user channel with the group interface.
This is fine, but in that case, shouldn't OfferFile also accept a handle
(perhaps 0 in the case it's a FT channel with one contact only?) so that
we can offer a file to members of the channel too? Or is the intention
you can offer one file to every member of a group? If so, how does that
actually work in practice?

* OfferFile returns an address, but the user is not allowed to connect
to it until later (the file transfer is open). Is the intention here
that the connection manager will do listen(), but not call accept() if
anyone connects, until the FT is established? It should be documented
thusly, otherwise the CM might promise an address, and then when the FT
is started, find the socket has already been

* Is it really valuable to seperate Remove and Cancel methods? Certainly
there's something odd going on here because I can pass something like
Remote_Error in to Cancel as a reason.

* Emitting TransferredBytesChanged should probably have some indication
of how often it should happen, in case some keen CM ends up emitting one
per byte transferred. I'm also a bit suspicious as to whether we need
this - is it so likely that one client will initiate a transfer and stay
around feeding bytes to the CM, but not be able to know how many bytes
it's written?

Regards,
Rob