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? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to thumbnailer in Ubuntu. https://bugs.launchpad.net/bugs/1532732 Title: Caching for arbitrary images on the web/remote hosts Status in thumbnailer package in Ubuntu: New Bug description: I frequently hit the use case that I query some host (might be in my local network, might be on the internet) for a list of things. The result set comes with images so I present a scrollable list of all those things to the user. Problem now is that with the images being fetched, the list scrolling is somewhat stuttery and also presents empty images at first which then are only filled with content a bit later. Scrolling the list back up, same thing again happens as the in-QML caches we have are based on RAM and with that can't hold tons of images. They are discarded and scrolling the list back up causes them to be reloaded. It would be great if the Thumbnailer could take care of this and fetch and cache them for the developer. One point to think about would be timeouts. Some use cases will always present the same image again. For example in kodimote I fetch the music artwork given by kodi. The artwork won't ever change, so the cache can be persistent. At the same time, fetching things from an online server *might* change over time. Ideally this would be configurable so that the developer can specify some cache time out for entries. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/thumbnailer/+bug/1532732/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
