[Bug 23819] Add high-level API for FileTransfer

[bugzilla-daemon at freedesktop.org]

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





--- Comment #13 from Andre Moreira Magalhaes <andrunko at gmail.com>  2009-09-23 06:19:39 PST ---
(In reply to comment #11)
> (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.
Ok

> > > 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?
Added invalidated with TELEPATHY_QT4_ERROR_INCONSISTENT (new constant)

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

Wrong:

Use case (without aboutToClose):
  - Input is a socket with 32k size
  - User writes 32k to socket at once
  - Code reads 16k and schedule another read 
  - Code reads the other 16k and finishes reading, but the transfer is never
finished as we don't know EOF is reached

Use case (with aboutToClose just finishing transfer):
  - 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) finish transfer which is not complete


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