Re: File Transfer API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2015-09-17 at 13:26 +0200, Christophe Fergeau wrote:
> Hey,
> 
> On Wed, Sep 16, 2015 at 11:23:46AM -0500, Jonathon Jongsma wrote:
> > ==========
> > 
> > We could deprecate this API, but I don't want to remove or break public
> > API. So we still need to support transfers created with the current
> > function. I'd like to propose a complementary API:
> > 
> > Add a new public object SpiceFileTransferTask with the following
> > characteristics:
> >  - it represents the transfer of a single file
> >  - it has a "progress" property, which represents the percentage of the
> > file that has been transferred. The application can connect to the
> > "notify::progress" signal to be notified when the progress of a transfer
> > changes.
> >  - it has a "finished" signal so that the application can tell when the
> > transfer of that file has completed
> >  - it has a "filename" property so that the application can display the
> > filename next to the progress of the transfer if desired
> >  - it has a "cancel()" method, so that an application can cancel an
> > individual file transfer[0]
> > 
> > In addition to this new object, add a "new-file-transfer" signal to
> > SpiceMainChannel. This signal will be emitted whenever a new file
> > transfer task has been initiated (presumably by the drag-and-drop
> > handler of the SpiceDisplay widget). 
> 
> This all sounds good to me, just one question, are you going to change
> 'progress_callback' to report total progress, or is it going to stay as
> it is now? (in other words, if an application only wants to display that
> current file transfer operation is N% complete regardless of the files
> being transferred, is there a way to do that?).


Yeah, this is basically unrelated to the additional API that I proposed,
so we can either choose to change this progress_callback or not,
separately from the decision about whether to add the new API. 

I would support changing progress_callback to report total progress, but
there's a slight hitch: internally all transfers are dumped into the
same bin. So let's say that you issue two calls to
spice_main_file_copy_async() sequentially:

 spice_main_file_copy_async(..., [files A and B], ..., prog_cb1, ...);
  - prog_cb1(bytes_readAB, [total size of A + B], ...);
  - prog_cb1(bytes_readAB, [total size of A + B], ...);
(while those files are still being transferred)
 spice_main_file_copy_async(..., [files C and D], ..., prog_cb2, ...);
  - prog_cb1(bytes_readABCD, [total size of A + B + C + D], ...);
  - prog_cb1(bytes_readABCD, [total size of A + B + C + D], ...);
  - prog_cb2(bytes_readABCD, [total size of A + B + C + D], ...);
  - prog_cb2(bytes_readABCD, [total size of A + B + C + D], ...);

You might expect that prog_cb1 would always report only the progress of
files A+B, and prog_cb2 to only report the progress of files C+D. But
unless we do some internal redesign, it would report all current
transfers. I'm not sure that this is a problem, and unless somebody
really wanted to change things, I'd probably keep the behavior above.
But I thought I'd mention it since there is a decision to make. 

Jonathon

_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]