Why do we need thumbnailing to be a service?
For user interface applications it makes relatively few sense to run the task of creating a thumbnail in the same context as the mainloop that draws the user interface. On the other hand if each desktop application starts creating either processes or worker threads that will be armed with thumbnailing code, then we will have a lot of threads and processes all running the same code;
Most applications link with a user interface toolkit that will happily deal with the vast majority of pixbuf shaped formats. That doesn’t mean that these toolkits will equally enjoy dealing with PDF, Office and video formats. There’s a lot of code involved here and we should try to avoid requiring everybody to load these complex pieces of code into their processes. I can give a few purely technical reasons like not heaving to map-in code that is not relevant for the application, reducing VmSize (although, admittedly, only things like VmRSS are really important). There are also a few political reasons, like patented formats. In the end I’ll just say it the way it is: it’s a bad architecture;
Application developers are really not very interested in developing LIFO queues and worker threads or processes that will handle the task of creating thumbnails;
Finally, application developers are asking for this (for example F-Spot). Creating thumbnails is not at all an exclusive task for the filemanager.
My proposal
Based on those conclusions I decided to write a DBus specification. I also reimplemented Maemo’s Hildon Thumbnail to be conform this specification. This work has been merged with the TRUNK of the project and will be used on Maemo‘s Fremantle release.
While rewriting Hildon Thumbnail I decided to make sure that the software compiles and runs on any normal desktop. This way the software can serve as a proof of concept and working prototype for the DBus specification. Special care was taken to make sure it feels as desktop neutral as possible.
I opened a bug to officially request a freedesktop.org project for this specification. I hope this organization will offer a platform for further development of this DBus specification. Hildon Thumbnailer can serve as a prototype and will be adapted whenever the specification improves.
Nice!
Shouldn’t the .thumbnails directory be a sub-directory of the $XDG_CACHE_HOME ( http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ), though?
Thanks for pushing this upward :)
I think the best argument for a service based architecture is that creating thumbnails takes a long time compared to the overhead of calling a service.
Is DBus routable? Can you make the DBus call to thumbnail say a .wrx file and if you don’t have a thumbnailer for that format it ask a central server?
@greg: there’s a method specified to introduce specialized thumbnailers. The generic thumbnailer will then route the request to your specialized one, indeed.
It’s in the specification under “Specialized thumbnailers”
We do not need any more services. We need existing services (modest mail check, browserd) to work properly. Once existing services stop hanging and/or gobbling system resources, I may support your proposal. But not a second before that.
Dude …
Neither Modest’s mail checker nor browserd have anything to do with what I’m working on right now. You should instead talk with the people involved in that.
Obviously aren’t other teams going to wait and do nothing until some other team’s problems have been fixed.
If you’d have even a microscopic small amount of understanding of how software development works, you’d understand that what you just wrote makes absolutely no sense.
@Mats Taraldsvik: No, there’s a specialized specification for thumbnails: http://jens.triq.net/thumbnail-spec/. This specification doesnt mention $XDG_CACHE_HOME (http://jens.triq.net/thumbnail-spec/directory.html). The people who wrote this specification are Jens Finke and Olivier Sessink. Although this specification is related to it, it didn’t change nor overwrite it. This specification only serves to manage the cache, not to define it.
“We need existing services (modest mail check, browserd) to work properly. Once existing services stop hanging and/or gobbling system resources”
Regarding stopping browser resource gobbling, I’m afraid you need to wait until internet keels over. Switching Flashplayer off or using flash-block is a good start though.
(Browser memory usage and performance are directly related to what and how many Flash ActionSript and JavaScript programs you run in your browser, how much data they download / create / copy etc.)
pvanhoof: Not sure if I got that.. So, you’re saying that the .thumbnail-directory could go in XDG_CACHE_HOME, and that the .thumbnail-spec doesn’t say anything about this ? ( I’m sure I saw /home/user/.thumbnails mentioned )
I’d think the thumbnails were cache items, and would belong there…
@Mats: I’m not saying the thumbnail-spec shouldn’t have used XDG_CACHE_HOME, I’m only saying that this specification (my DBus one) is not attempting to solve thumbnail-spec’s issues.
To fix those issues you should talk with Jens Finke and Olivier Sessink. This DBus specification will follow whatever the thumbnail-spec defines as cache directory and cache format. This DBus specification wont try to redefine it nor will try to fix it (if there are problems).
If the thumbnail-spec has problems, then address those to Jens and Olivier and maybe they will make a new version of the specification.
I had to choose “a” cache format and I chose the thumbnail-spec for this.
Else I would have people complaining that I have a NIH syndrome. Now I have people complaining that thumbnail-spec has problems.
And in the end … such complaints usually don’t really matter: they are just complaints because people enjoy complaining.
Again, I repeat, and I will infinitely keep repeating this: address thumbnail-spec’s issues to Jens and Olivier. This specification is a DBus one for managing the cache as defined by thumbnail-spec. This specification is not thumbnail-spec. This specification depends on thumbnail-spec. Therefore wont this specification try to fix thumbnail-spec, nor is it trying to redefine it. Nor will it ever try to redefine it. Nor is the purpose of this specification trying to redefine it. Therefore it wont.
This DBus specification will, however, adopt any new version of thumbnail-spec. Which means that you can get it fixed by addressing your issues at Jens and Olivier who maintain the thumbnail-spec. Not me.
I don’t know how much more clear I can write this down.
Okay, you’ve hammered the point home. :) I’ll try to contact them…
make it happen! just realised i wanted a gravatar-thumbnailer for my gtk-gitnub-thing. i guess i’ll have to go with a worker-thread for now..