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

[Philip Van Hoof <spam pvanhoof be>]

(resend, as I was not subscribed on this mailing list)

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