My problems with the thumb spec

[Thomas Leonard]

On Sun, May 18, 2003 at 02:45:32AM +0200, Kai Wetzel wrote:
[...]
> ...sorry for joining the discussion so late. I've re-read some of the
> earlier threads on the TMS in my mailbox and I'll comment on some
> of those suggestions but I'll focus on the latest debate.
[...]
> #6 UNIX mtime vs. MTime attribute in PNG thumbnail file
> 
>    This decision should be explained more clearly in the standard
>    or else it will come up again and again. The reason given
>    is that basically a younger mtime of an invalid thumbnail could
>    result if the image is replaced with an older one,I think. (Hmm)

I don't think Mosfet was suggesting that. He wanted to set the mtime of
the thumbnail to that of the source, not the thumbnail's creation time.
Both approaches are equivalent. Mosfet's is slightly faster in an unusal
case; the current one is more consistant with the way the size is stored.

> #6 One large folder with MD5 for each file vs. MD5 directories &
>    individual files without MD5
> 
>    Unfortunately, few _facts_ have been presented about this issue.
>    The case about one large directory has been backed off with readings
>    for NFS but I don't understand why it's actually faster (must be
>    some weird NFS implemetation detail). A few points:

Note that my arguments against the original plan do not apply to Mosfet's
proposal. I argued that splitting a logically unified directory (full of
MD5 sums) arbitrarily into subdirectories was an ugly premature optimisation;
something the kernel should, and probably would, do automatically and
better.

Mosfet's proposal organises the subdirectories by their sources. When
showing thumbnails for a directory under the original plan, the thumbnails
would be split over all the subdirectories, forcing lots of seeking.
When subdirectories are the MD5 sums of the source directories (not the
first two characters of the MD5 of the whole path, as before) all the
requests come from a single directory, which may indeed give better
performance. It also makes more sense for a user if they decide to browse
the thumbnails directory.

Possible arguments against:

- It involves yet another change to the spec, just when it was starting to
  look stable.

- When thumbnailing remote resources, you could end up with a huge number
  of subdirectories.

- When thumbnailing files on filesystems with long filenames, the
  filesystem hosting the cache must support them too.

None of these arguments bother me particularly... it's too late for the
next stable release of ROX-Filer to support a new system, but both could
coexist, while wasting some space. It would be really good to declare the
spec as stable at some point, though!


-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r at ecs.soton.ac.uk		tal197 at users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1