[Bug 23819] Add high-level API for FileTransfer

[bugzilla-daemon at freedesktop.org]

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





--- Comment #11 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2009-09-23 05:52:57 PST ---
(In reply to comment #9)
> I checked the code and QFileInfo::fileName does not do any IO at least on unix.
> Should I still remove the parsing?

Keep it, I suppose. It's an easy way to comply with the spec's recommendation.

> > Yeah - nothing else would be safe (we're missing a piece of the file!). I think
> > we have a TpQt4-specific error string somewhere already that means "CM is being
> > stupid", equivalent to TP_DBUS_ERROR_INCONSISTENT in telepathy-glib? If we say
> > "please start from offset 1234" and the CM replies "starting from offset 2048",
> > we should invalidate the Channel with that error, and close it.
> Yep, already implemented :)

It looks as though you just cancel() it?

> In the outgoing case we are not reading everything from input all the time, we
> read from blocks (16k now) so there may still be data to read.
> 
> From Qt QIODevice::aboutToClose docs, "This signal is emitted when the device
> is about to close. Connect this signal if you have operations that need to be
> performed before the device closes (e.g., if you have data in a separate buffer
> that needs to be written to the device)."
> 
> I just do this for sequential devices, as we probably don't want to readAll for
> a file for example, so this was the only way I found to check "EOF" was reached
> when using sequential devices.

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


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