Comment 13 for bug 1224998

@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.)

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.