After discussing this with James, here are some thoughts. Adding direct download of arbitrary remote images opens an attack/bug vector. For example, a caller could ask for http://<whatever> and it turns out that the remote server (maliciously or otherwise), is very slow, or doesn't respond at all until the request times out. This means that one application can disable access to remote images for other applications because the thumbnailer allows only a limited number of outstanding HTTP requests at a time. Or the server could potentially return garbage images each and every time, each of which would result in an entry in our failure cache. That can have negative performance impact on other apps.
But, I don't think all is lost. The pragmatic answer to the problem would be for the application to download the image (or audio file, or whatever) and simply drop it into the file system somewhere. Then pass a URL to that file to the thumbnailer, and it will do the rest (extraction, scaling, rotating, caching, etc.) This isn't quite as convenient as having the thumbnailer do all of the work, but I think it might be workable? I'm open to suggestions though. I agree that having this feature would be really nice. But we'd have to sort out the potential denial-of- service/reliability issues. If the actions of one application can disable access to thumbnails for other applications (or significantly reduce throughput), we have a problem. -- 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
