On 19.09.2013 09:05, Jussi Pakkanen wrote: > @michal: limiting the amount of queries is a good thing but having > cancellables might not be the best way to achieve that. There needs to > be a rate limiter somewhere but it is uncertain what is the best place > for it. > > The thumbnailer should not place arbitrary limits on how much work it > does. There may well be cases where someone wants to shove 1000 queries > in and expect them to be done as fast as possible. Therefore the > limiting on query speeds should be done outside the thumbnailer. > > Furthermore we had a discussion on the API it should provide and we came > to the conclusion that it should be done in a similar way to Unity-API. > That is, it can not expose any implementation details (be them Qt, or > anything else). The reason for this is that this service is useful for > all kinds of applications and we should not arbitrarily limit it to Qt > apps. (There could be Qt wrappers, of course.)
Sure, of course - the Qt image provider implementation would just be one of them. > Any app using the thumbnailer could use whatever tasking or queue > mechanism they choose. Basically it would boil down to having a worker > thread with a QQueue of strings and resolving them one by one. > Cancellation would then just be a case of calling clear on the queue. > This is massively simpler to implement than trying to make third party > code (gstreamer, http downloading and the like) cancellable. The only > downside is that you can't cancel the in-flight query, but since there > is only one, it is not an issue. > > This would also decouple queueing strategy from thumbnail generation so > all applications could have their own strategy and they could alter it > without any code changes on the generator side. Right, that does give better flexibility, but creates additional work for all the consumers. All in all, my requirements were high level ones, and they stand. And I don't expect to have to implement the default Qt image provider, for which the behavior we described above seems to cover most of the usecases - LIFO queue with the ability to drop things from the queue when the corresponding consumer is destroyed (cancelling "in progress" jobs is probably not needed). -- Michał (Saviq) Sawicz <michal.saw...@canonical.com> Canonical Services Ltd. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1224998 Title: Cache preview and thumbnail images To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1224998/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
