Created attachment 233559 [details] [review]
util-app: Make copy_file() available to other classes

Created attachment 233560 [details] [review]
downloader: (Try to) Support non-HTTP cases

This is not guaranteed to work for every kind of filesystem but at least
now we don't assume HTTP blindly and support caching from local
filesystem. Its a perfectly valid usecase for distros to provide product
logos or driver files from local filesystem and with this patch we'll
support that.

Review of attachment 233559 [details] [review]:

ack

Review of attachment 233560 [details] [review]:

::: src/downloader.vala
@@ +62,2 @@
         try {
+            if (uri.has_prefix ("http://"))

What about https? and upper case strings?

I think you should use remote_file.has_uri_scheme() instead.

Review of attachment 233560 [details] [review]:

::: src/downloader.vala
@@ +62,2 @@
         try {
+            if (uri.has_prefix ("http://"))

Wouldn't HTTPS require some kind of authentication that we haven't yet implemented?

And g_file_has_uri_scheme takes care of case?

nah, https is not authentication, just encryption, although we will not be doing any certificate checks, so its not MITM proof.

has_uri_scheme takes care of case.

(In reply to comment #2)
> Its a perfectly valid usecase for distros to provide product
> logos or driver files from local filesystem and with this patch we'll
> support that.

Is this the initial motivation for this patch series? Can't we look for files in some well-known location in addition to ~/.cache if we want to let distros ship the various logos/drivers?

(In reply to comment #7)
> (In reply to comment #2)
> > Its a perfectly valid usecase for distros to provide product
> > logos or driver files from local filesystem and with this patch we'll
> > support that.
> 
> Is this the initial motivation for this patch series? Can't we look for files
> in some well-known location in addition to ~/.cache if we want to let distros
> ship the various logos/drivers?

Its not about us looking for the cache but rather the source files being on the local (or non-HTTP) filesystem already. i-e we'll get file:///some_path.jpg for a logo from (perhaps a custom) libosinfo database. Same goes for drivers. As you know I'm trying to get qxl drivers installed by default for windows and I did this for one of my approaches for that. Then I realized these patches would be nice to have anyways.

Created attachment 234134 [details] [review]
downloader: (Try to) Support non-HTTP cases

v2: Make use of g_file_has_uri_scheme() and also handle HTTPS through libsoup.

Using a local cache is imho important too, but thats bug 691495. This simple patch seems to make sense too.

Review of attachment 234134 [details] [review]:

ack

Yup, it makes sense to be able to download from ftp or whatever. 
But it's a very convoluted way of letting distros preinstall the drivers (ie they have to install them somewhere on the FS and then write custom libosinfo database files, or patch the existing ones to use the correct drivers).

(In reply to comment #12)
> Yup, it makes sense to be able to download from ftp or whatever. 
> But it's a very convoluted way of letting distros preinstall the drivers (ie
> they have to install them somewhere on the FS and then write custom libosinfo
> database files, or patch the existing ones to use the correct drivers).

This would be mainly a way for them to install new drivers, not patch/update existing ones (though they can use it that way too). There could also be a third-party package that adds additional stuff to libosinfo/Boxes, e.g some proprietary drivers.

Attachment 233559 [details] pushed as 22d3cb1 - util-app: Make copy_file() available to other classes
Attachment 234134 [details] pushed as 9ce057b - downloader: (Try to) Support non-HTTP cases