cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Kreipke" <>
Subject RE: Cachability (was RE: XInclude Transformer vs CInlude Transformer)
Date Fri, 14 Jun 2002 15:56:55 GMT
Carsten, Conal,

> > But actually my question is about caching of the DirectoryGenerator and
> > sub-classes. It seems to me that these transfomers should also be
> > cacheable;
> > maybe this is just an oversight too? Or is there something tricky
> > I haven't
> > forseen? ;-)
> AFAIK, the directory generator can be made cacheable as well, the
> only reason why it isn't is, that noone has done it yet, I think.

It depends on (as Carsten mentioned) the ability to detect that a
directory's contents have changed. Especially when diving down more than one
level using 'depth'.

Under Windows (don't kill me), I believe that directories are only modified
when the _list_ of files changes, not when a file is modified. In other
words, it's hard to detect that files' details have been modified without
getting those details, since you can't tell from the directory.

However, under Windows, there's a COM 'listener' API where you can register
a callback object to be notified when a directory or _any_ of its contents
are changed. Is there such an object/interface in Java? Perhaps in JDK 1.4?
Or, how about a COM wrapper object?

And that of course leaves Unix/Linux for which I have no idea.


> > I could enhance it to only traverse PART of the file system
> again to check
> > the validity, by keeping a record of the file and directory
> > objects involved
> > in the last search. In the case of a directory search like
> "images/*.jpg",
> > or "docs/*.xml", the generator should only need to check the
> timestamp of
> > the "images" or "docs" directories, is that right? I've also
> used searches
> > like "images/{1}.jpg" with the ImageDirectoryGenerator, to get the image
> > width and height into a pipeline that converts the jpg to svg,
> > for scaling,
> > etc. In this case the validity could depend on the timestamp of
> > that single
> > file.
> Yes, collecting the files involved together with their last modification
> date is another possibility.

Without a 'listener' as described above, I'm not sure how this would
actually speed things up, you're still checking the lastModified date using
the File object.

That said, there are a couple of simple fixes to be made to the
ImageDirectoryGenerator and MP3DirectoryGenerator where caching will
significantly speed it up. I'll start a separate thread.


To unsubscribe, e-mail:
For additional commands, email:

View raw message