Re: GnomeDesktopThumbnail API replacement

[Debarshi Ray <rishi is lostca se>]

On Thu, Feb 01, 2018 at 10:33:58PM +0100, Bastien Nocera wrote:
> But we could make some internal changes to that API to allow you to
> pass associated metadata, maybe, so you could do something like:
> - tell the thumbnail API to only consider this private thumbnailer you
> have, and no other
> - find a way to pass 2 files, or maybe one file and a serialised
> string/metadata to the thumbnailer which would do its job.
>
> There's currently no way to do the 2nd part, but I'll try to see
> whether we can make the API extensible at least, so writing something
> like that is possible.

Ok. Thanks for looking into it.

> > (One thing that I didn't mention so far is that Photos also has
> > online thumbnailers.  They grab server-side generated thumbnails
> > for online content which sometimes requires credentials for the
> > GOA account. Currently these are in-process and are a glorified
> > g_file_copy over HTTP.)
>
> The thumbnailing processes are sandboxed with no network access right
> now. I don't think that's something we want to change, but it just
> makes it a 2-step process.

Yes, we shouldn't let the local thumbnailers have access to the network.
This is why, currently, the custom local thumbnailer in Photos doesn't
handle online content. The online content is thumbnailed inside the
main application process.

I wonder if it makes sense to split the online thumbnailing into a
second out-of-process thumbnailer that can be sandboxed with a
different set of restrictions. Maybe not? It's a fancy g_file_copy,
so it already goes through GVfs' out-of-process HTTP backend. Maybe
the GVfs' daemons should be seccomp-ed instead?

> [1]: This is the latest attempt, just the sync version:
> PROPERTIES:
> [...]
> - number of threads in the thread pool

Oh, yes, that's another thing that I currently use to prevent the
thumbnailing from clogging up the GTask thread pool.