RFC: Extending GIO API for bulk file transfers/multiple files

[Tomas Bzatek <tbzatek redhat com>]

Hello list,

I have a student working on gvfs-archive write support (see related
https://bugzilla.gnome.org/show_bug.cgi?id=589617) based on libarchive
internal writer. 

Certain operations like deleting files from existing archive are not
cheap; you usually need to rewrite whole archive excluding the files
you don't want. With the current design of gvfs-archive and GIO in
general we sacrifice performance for flexibility. Also for copy/read
operation this means opening an archive, seeking to the particular
file, decompressing all the read contents in between in case of
streaming archives (e.g. tar.xz) and finally decompressing the required
file out. That all repeats for every file requested, in order to handle
multiple copy operations at the same time.

So I was thinking about limiting gvfs-archive to handle only one
concurrent operation (a real performance drawback is to be measured)
and also introducing new API. Either we can add a counterpart for
g_file_{copy,move} handling a list of GFiles or a "start/stop"
function-couple to mark the active mount as ready for series of block
operations. Both ideas are silly and would only bring troubles e.g.
when application forgots to call the "stop" function.

The benefits specifically for gvfs-archive would be drastical
performance boost and better control of archive consistency, e.g. when
closing a newly created one. However we all don't want to get back to
xfer difficulties in the gnome-vfs2 old days...

Please discuss, I'm open to any suggestion.
-- 
Tomas Bzatek <tbzatek redhat com>