On Fri, 2009-05-15 at 12:34 +0200, Alexander Larsson wrote: > On Fri, 2009-05-15 at 04:00 +0200, Jannis Pohlmann wrote: > > > I think we should improve the description of Unqueue a little bit. > > Unqueue doesn't really prevent service-side implementations of unqueing > > batch tasks (more than one URI queued as one handle) in the middle of > > the task (e.g. after having generated thumbnails for 2 out of 10 URIs). > > > > This is exactly what e.g. file managers need though. Just imagine a > > file manager enters a directory, queues all its files for thumbnailing > > and then switches the directory before all files are processed by the > > thumbnailer. So IMHO it should be pointed out more clearly that this is > > not a violation of the spec. Right now it just says "You can't unqueue > > requests that are currently running." This should be something like > > "You cannot cancel the processing of individual URIs but thumbnailers > > are free to support cancelling running tasks between the processing two > > URIs when a task unqueued." > > I don't think using this spec from a file manager is really a good idea, > its quite a lot of overhead doing all this dbus i/o when loading a large > directory. I certainly won't be using it in nautilus.
The DBus overhead is not really measurable compared to the time it takes to make a thumbnail. Well, everything is measurable, but the question is whether it's actually significant. With the EPeg library, of course, thumbnails are made quite fast. But still not as fast as a DBus latency overhead. By far not. > I brought this up with philip when this was initially proposed, and the > sense that I got from him was not that the file manager is meant to > consume this interface, but rather to implement it. Ok, yes. Nautilus would be a good place to implement the DBus interface. That's because Nautilus, on the GNOME desktop, holds the code for thumbnailing at this moment. To enable the GNOME desktop to have this interface it would be most easy, and from an architectural point of view totally fine, if Nautilus would implement it. It would be equally fine if another process would. Meanwhile if Nautilus developers are worried about the DBus overhead for their own thumbnailing purposes, then they can just side-step the DBus interface and do the thumbnails in-process instead. The DBus thumbnailer spec doesn't forbid other processes from writing in the thumbnail-spec's dirs (the storage spec), so even if Nautilus wouldn't be the implementer, then still it can use its own current code. Just rename (filename.png.part, filename.png), otherwise different processes could pickup a half-ready filename.png. I'm pretty sure this is in place like this already in Nautilus? -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
