[Spice-devel] [PATCH spice-gtk V4 1/3] file-xfer: handling various transfer messages in main channel

[Marc-André Lureau]

Hi

On Fri, Jan 4, 2013 at 9:34 AM, Dunrong Huang <riegamaths at gmail.com> wrote:
> spice_main_file_copy_async() was designed to copy multi-files at a
> time, which I think is a little unreasonable:
>
> 1) If something error happens when opening or reading a file. should
> we report error immediately(using callback), or wait for all tasks to
> complete?

Report error immediately.

> 2) We have to set group_id to identify tasks created at the same
> time(e.g. for report_progress, report_finish, ...)

With a single request, we wouldn't need the group id.

> 3) For reporting progress, we have to calculate all tasks' remain
> bytes(see report_progress()), this is a bit weird. It should be done
> by caller of this API(just as nautilus does).

I don't understand what is the problem, I mean each file has a size we
can query when starting the copy. What else would you expect the
caller to do?

> 4) After a task is finished, we have to check whether other tasks with
> same group_id have been finished(see report_finish()). I think it's a
> bit weird.

Indeed, we have to wait for all files to be copied before reporting
success for the whole operation. Progress can be reported regularly
via callback.

> If spice_main_file_copy_async() only copys one file at a time, our
> code will be more simple and clean. The caller of this API can
> implement
> coping multi-files, just as nautilus does.

But that would be inefficient and cumbersome if the caller has to
request each and every file. (especially for recursive copy, where
each caller implementation would have to implement diving through
subdirs). I don't think there are good technical reasons to split each
file in a seperate request. However, you can implement the copy ()
method to be limited to a single file atm, with a g_return
pre-condition. Support for many files and dirs can be added later.

cheers

--
Marc-André Lureau