[Bug 23819] Add high-level API for FileTransfer

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=23819


Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|24110                       |




--- Comment #15 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2009-09-23 06:28:31 PST ---
(In reply to comment #13)
> > It looks as though you just cancel() it?
> Added invalidated with TELEPATHY_QT4_ERROR_INCONSISTENT (new constant)

Oh? I thought we had that already?

> > Perhaps the right handling is to ignore the sequential/not distinction, on the
> > basis that we have to read the rest of the data for correctness, and we
> > shouldn't get aboutToClose from a file (at least until we've read everything).
> I would stick with this code, or we would not work with sequential devices in
> most cases.
> 
> Correct:
> 
> Use case (with aboutToClose):
>   - Input is a socket with 32k size
>   - User writes 32k to socket at once
>   - Code reads 16k and schedule another read 
>   - Input is closed
>   - (aboutToClose) Read the other 16k and send to output

We essentially have two cases, seekable files and non-seekable pipes (I'm not
clear on how the Qt terminology works).

Perhaps I was unclear. I think we should do this (the "non-seekable pipe" code
path) for *all* objects, including files - if this behaviour is necessary for
correctness, then it's necessary for correctness, and we should always do it.

I conjecture that in the seekable file case, aboutToClose will never be emitted
with "much" data remaining - so the practical behaviour of the code will be the
same as we currently have.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.