[Telepathy] FileTransfer: integrating with annoying APIs

[Sjoerd Simons]

On Fri, 2010-10-29 at 11:43 +1100, Danielle Madeley wrote:
> On Thu, 2010-10-28 at 12:39 +0100, Sjoerd Simons wrote:
> > On Thu, 2010-10-28 at 15:32 +1100, Danielle Madeley wrote:
> 
> > 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.
> 
> So Empathy does call ProvideFile immediately, but the spec is vague. The
> State property kind of implies you should be waiting for Accepted. The
> description at the top says you can call ProvideFile immediately though.
> It seems that you might need to fake the Accepted state in order to
> guarantee having ProvideFile called.
> 
> http://telepathy.freedesktop.org/spec/Channel_Type_File_Transfer.html#description
> http://telepathy.freedesktop.org/spec/Channel_Type_File_Transfer.html#File_Transfer_State

We should clarify this then :)

> > 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).
> 
> At the moment the client will only stream once the channel has entered
> the Open state, so we still need a new state saying to start streaming
> the data (we need the data before the transfer begins). The idea of the
> property is to tell clients whether to open during the Open state or the
> Prespool state.

Why would they not always start streaming right away. Again i don't see
the point of having a property which basically comes down to spec
saying: You can start streaming to the CM at any point, except when this
property is set then you MUST start streaming right away otherwise
things just won't work.

Why not just mandate that clients MUST always start streaming as soon as
possible? (Yes that would mean fixing existing clients, but introducing
a new property would as well)


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