[Telepathy] FileTransfer: integrating with annoying APIs

[Sjoerd Simons]

On Thu, 2010-10-28 at 15:32 +1100, Danielle Madeley wrote:
> So there are a bunch of File Transfer APIs that we want to integrate
> with (i.e. libpurple) that talk in file names, rather than sockets.
> 
> It turns out to be straight-foward enough to implement receiving with
> such an API, we can receive to a temporary file and then splice the
> contents of that file into a socket back to the client.
> 
> Sending is harder.
> 
> In order to get the client to call ProvideFile we need to ACCEPTED. Then
> we need to set state OPEN in order to actually be sent the file, so that
> we can then write it into a temporary file and send it.

That's an implementation detail of the client you're using, in the
specification the states and when you can call ProvideFile is completely
seperate. The only link between the two is that the state machine cna't
move to the Open state before you call ProvideFile (as it obviously
can't start transferring data before getting file data).

Ofcourse this is subtle and for a client it's easy to see why it would
assume there is no point in calling ProvideFile before seeing the state
move to Accepted.

> The problem here is that we then don't know whether the remote client
> actually accepted the transfer or not.
> 
> I'm proposing we extend the spec with an extra state and extra property,
> specifically for sending files: property PrespoolRequired:b and state
> PRESPOOL.
> 
> The PrespoolRequired property would indicate that the client should call
> ProvideFile() immediately without being concerned about whether the
> channel is pending or not.
> 
> The PRESPOOL state would then indicate that the client should begin
> sending the file (once ProvideFile has been called).
> 
> Once the file is sent to the CM (and the CM can offer the file to the
> remote) the channel would return back to the PENDING state until it is
> accepted. It would then enter the OPEN state and the transfer would
> proceed as normal.

I think all we need is to make it clear/require that clients should
always call ProvideFile as soon as possible and should not wait until
the state moves to Accepted. I don't see the point of having a special
property that says: For this specific FT the requirements is  more
strict. We should just make it more strict in all cases.

On CMs that need a local copy from the file they can start copying
immediately, on CM that just stream data they only start reading when
they need it (like they already do as setting up the actual data stream
can take some time after the remote end accept the FT).

Ofcourse it's impossible for observers to see when the handler is
transferring data during the pending state vs. actually waiting for the
remote end to accept but i don't think that's too big an issue.

-- 
Sjoerd Simons <sjoerd.simons at collabora.co.uk>
Collabora Ltd.