Comment 4 for bug 1532732

Revision history for this message
Michi Henning (michihenning) wrote :

All good points, thanks!

Currently, there is one thumbnailer service instance for all apps/scopes that are run by the user. So, it's one per user. (We could have one for the entire system though equally well, but that's currently moot, seeing that phone isn't multi-user, at least not concurrently.)

Downloads happen on the server side because dash.ubuntu.com is the only remote image source, and the results from there can be shared among all apps. So, it made sense to do it on the server side.

For your use case, downloading on the client-side would probably be the way to go. We could implement this on behalf of the caller inside the client API, so there would be no extra work for customers.

But we still need to secure this somehow. If the client gives us a URL, and we download (on the client-side) on behalf of the caller, we now have to put the thumbnail somewhere in the file system. The caller then would have to provide the path name to that file as usual and the thumbnailer would make sure that the client is allowed to read that file before handing out a thumbnail (as it does now).

But we don't want to accumulate garbage. When the thumbnail falls out of the cache, the file that was created by the client-side API needs to be removed too. Otherwise, we burden the caller with the need to explicitly remove stale files. That's a sure-fire guarantee for accumulating dead files over time, so I don't want to go there.

Or we could fetch the thumbnail on the client side, shoot it over the wire for thumbnailing and caching, and return some token to the client that is going to identify that thumbnail until it expires. But that makes for an awkward API too, because now the client has to garbage collect the tokens, so we haven't really solved the problem.

Yet another option would be to make the thumbnailer embeddable. If the client wants to thumbnail arbitrary things, they run their own thumbnailer inside their own address space. That gets rid of all the security concerns immediately. The thumbnailer hasn't been designed to be embeddable, but I don't think it would be all that difficult to allow this. The client-side API is pimpl'd already, so we can probably bolt all the other stuff (bypassing the DBus level underneath) without too much difficulty.

Opinions?