Re: GnomeDesktopThumbnail API replacement

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:
- 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.

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