Comment 13 for bug 1550706

This looks doable, at least in principle, but raises a few questions.

How does the thumbnailer decide *where* in the file system to write the file? Note that, if the file gets written somewhere where other applications can read it, this will potentially allow application B to see a thumbnail created by application A, provided application B knows the path name.

How do we clean up the files that are created that way? We could do it as soon as a thumbnail request for the file completes, but that would mean that we write the entire file into the file system for each thumbnail request, which is horribly expensive. It also would effectively disable caching because inode number and modification time are part of the lookup key into the cache.

If we don't clean up files immediately, when and how do we do it? One way might be to have a small persistent cache on the client side that maps qrc URLs to path names. We could then delete a temporary file when its entry falls out of the client-side cache. (There are callback hooks in persistent-cache-cpp that make this possible.) But it feels a bit hacky. For example, a crash at the wrong moment can mean that we accidentally leave a file on disk behind, so that we still would have to add a garbage collector for the temporary files. Sizing the client-side cache correctly is also problematic. (50 video files are very much larger than 50 photos.)

I'm not trying to rain on the party here. But we need to have a strategy for dealing with this before we implement something, only to find out that it's too expensive or clunky. Part of the problem seems to be that the qrc files create a virtual file system, instead of having real things in the real file system. This makes it difficult to leverage other tools that operate on files.