Re: Thumbnailer specification: Move, Delete, Copy hints (Was: Re: GSD should not housekeep the thumbnails)

[Philip Van Hoof <spam pvanhoof be>]

For the people new to the discussion about the thumbnailer DBus spec,
here's[2] a working prototype that will compile on a typical desktop.

If you have Gdk and GStreamer, it'll already make thumbnails for all
supported formats in GdkPixbuf and for mpeg videos. More formats, if
supported by GStreamer, will follow.

Of course can specialized plugins be made. Those plugins can be ran
either in-process with the prototype's daemon implementation, and as a
separate process (if it implements being a specialized thumbnailer as
defined by the Draft specification[1])

[1] http://live.gnome.org/ThumbnailerSpec

[2] https://stage.maemo.org/svn/maemo/projects/haf/branches/hildon-thumbnail/daemonize

With the prototype you can run plugins designed to be ran in-process
with the prototype's daemon implementation as a standalone specialized
thumbnailer. You use the "plugin-runner"[3] tool for that.

[3] https://stage.maemo.org/svn/maemo/projects/haf/branches/hildon-thumbnail/daemonize/daemon/plugin-runner.c

This prototype is designed for desktop neutrality. Although it depends
on glib, gobject and dbus-glib, you can easily make plugins that avoid
the dependency on GdkPixbuf or GStreamer. 

You can easily adapt the Makefile.am to either build or not build them.

I will improve the code and will accept patches that make it even more 
desktop neutral (if it makes sense).

If even that is not okay, the specification allows for "competing
implementations". It even allows for a desktop-search engine or a file
manager to become an implementer of it. The spec is designed for this.

I also want (and can[4]) help competitors with this as I believe that
competition is a innovation-force. It's necessary and good to have a
competitor, to drive innovation. I'll welcome it, strongly.

I strongly believe that thumbnailing is something that will have
different characteristics on a mobile compared to a desktop. It indeed
make sense to have competing implementations.

[4] During daytime I can help with coding tasks related to this. But
people need to ask me, of course.

The prototype also shows how you could implement a toolkit specific
thumbnailer library that could be consumed by your application
developers. [5] is a reimplementation of libhildonthumbnail.so that now
uses the prototype daemon instead.

[5] https://stage.maemo.org/svn/maemo/projects/haf/branches/hildon-thumbnail/daemonize/thumbs/hildon-thumbnail-factory.c


Thanks


On Tue, 2008-09-16 at 14:42 +0200, Philip Van Hoof wrote:
> On Tue, 2008-09-16 at 13:30 +0100, Rob Taylor wrote:
> > Emmanuel Pacaud wrote:
> > > Hi,
> > > 
> > > On mar, 2008-09-16 at 11:34 +0200, Stephane Delcroix wrote:
> > >> Hey guys,
> > >> The plugin does something like this:
> > >> - clean the thumbnails older than MAX_AGE (default to 60 days)
> > >> - clean the oldest thumbnails until the cache size is under MAX_SIZE
> > >> (default to 64MB)
> > > 
> > > I don't get why it work like this. Why remove a thumbnail because it's
> > > old ? Why would we want to limit the size of the thumbnail cache to an
> > > arbitrary value ? It depends on the disk size, and it will limit itself
> > > by the fact the size of the thumbnailed files is largely bigger than the
> > > thumbnail size.
> > > 
> > > Wouldn't it be better to just remove thumbnail of files that don't exist
> > > anymore ?
> > 
> > I guess when Philip's thumbnailer daemon is starting to get widely used,
> > It could do the job of cleaning the cache. This would mean that you
> > would no longer have thumbnails lying around for deleted files and it
> > could also clean out thumbnails that haven't been *accessed* after a
> > certain time period, which should give better performance.
> 
> Related to this discussion ... adding Andrew den Exter in CC, as I had
> an interesting conversation with Andrew about this.
> 
> So although the current Draft specification mentions a Move, Delete and
> Copy, according to Andrew (and I agree) this ain't necessary at all.
> 
> http://live.gnome.org/ThumbnailerSpec
> 
> A properly written thumbnailer, in modern days, would have a file
> monitor on each thumbnailed original and/or would initially scan all the
> thumbnails, read the exif info to get the original's location, and would
> do housekeeping fully automatically this way.
> 
> I don't know whether or not I should keep the Move, Copy and Delete
> hints in the specification. I'm in indecision-mode about it.
> 
> Important note that you want to make thumbnailer daemons activatable by
> DBus (with a so-called .service file) and that some implementers will
> want to shut their daemon down after n minutes of inactivity. Meaning
> that simple file monitoring wont be sufficient.
> 
> The current infrastructure, that is not guaranteed to be running on
> every desktop (nor every tablet), are desktop search engines like but
> not only Tracker, Beagle, Strigi, etc ... these are doing file
> monitoring at large scales already. It would make sense for them to
> perform the house-keeping by giving hints to the thumbnailer like Move,
> Delete, Copy, etc.
> 
> Which is why I think I should keep the methods in the specification, and
> explain that there's no requirement for the thumbnailer himself to do
> housekeeping (although it is allowed to do this automatically). But that
> there's a requirement to "accept the hints". Not a requirement to
> process the hints, just to accept them, and an advise to process them.
> 
> No desktop search engine and a wrong thumbnailer could indeed mean that
> neither of the two will make cached thumbnails get removed.
> 
> Chicken & egg, I don't like it, but I also don't know if I should
> require anything about this, by specification.
> 
> 
> Again, I'm in indecision mode about it.
> 
> 
-- 
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