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 _______________________________________________ Telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
