[Bug 41332] [patch] Support resuming file transfer

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41332

Olli Salli <ollisal at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|telepathy-bugs at lists.freede |daniele.domenichelli at gmail.
                   |sktop.org                   |com

--- Comment #1 from Olli Salli <ollisal at gmail.com> 2011-10-04 08:15:28 PDT ---
A few problems with the patch:

1) The output stream is not necessarily sequential. It might, for example, be a
socket for relaying the data to some other process, or some custom QIODevice
for e.g. storing the data to a database or alike

2) It's not documented that a seek is now made by acceptFile()

3) It changes existing, public, exported library API to have additional side
effects for objects passed to it from the user. This is an API/ABI break and
hence unacceptable.

Solving 1 would be possible by treating sequential (e.g. QFile) and other
QIODevices differently via the isSequential accessor. This would, however, be
confusing in my opinion.

Solving 2 would of course be easy.

3 however can only be solved by retaining the behavior of the current function
and adding a new one (an overload if params differ, or otherwise one with a new
name) for easy resumes. You could add an overload:

acceptFile(QFile *file)

which would be documented as the one to use when you have an existing (but
partial) file the user wants to complete by this file transfer, that you can
directly access. It would take the size of the file, open if not open already
(in append mode to preserve the already received part) and pass the file's size
as the requested offset to acceptFile(qulonglong, QIODevice *).

Of course, one could do that sequence in their own code, but clearly it's not
intuitive that this is required. Hence, I'd very warmly welcome a patch adding
that "resume to complete this file" overload.

Also, maybe instead of being an overload it'd be better to call that new
function resumeToFile() or something like that. Ideas welcome.

I'm assigning to you, but if you don't feel like cooking this patch, feel free
to reset assignee to default, and turn this into a feature request (prio:
enhancement) to have a nice convenience overload for resuming incoming FTs.

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