touch-packages team mailing list archive

[Michi Henning <michi.henning@xxxxxxxxxxxxx>]

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