[Telepathy] file transfer spec comments

[Marco Barisione]

Il giorno gio, 07/02/2008 alle 21.02 +0000, Robert McQueen ha scritto:
> * 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?

Yes, for instance you could have nautilus-sendto that sends the file and
empathy-ft-chandler that show the progress.
If there is an error before empathy-ft-chandler is executed then it
won't receive FileTransferChanged (and neither NewFileTransfer) but it
will be able to show the status using the data returned by
ListFileTransfers().

> * 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?

To be honest I don't know and I didn't consider the muc case.

> * 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

This was discussed some months ago on IRC. We decided to return the
address to avoid adding another function just to get the address.

In my implementation in salut I don't do a listen() so someone could use
the same socket but this is not a real problem because sockets a created
in a private directory.
Probably it's a good idea to remove the address return value and add a
new GetAddress() method.

> * 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.

After a call to CancelFileTransfer() the ft is not removed from the list
returned, so empathy-ft-chandler can show also cancelled file transfers.

> * 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?

As Xavier said it's needed because empathy-ft-chandler shows the
progress but the file is sent by nautilus-sento (or empathy or
whatever).

-- 
Marco Barisione
http://www.barisione.org/