Return-Path: 
 <cocoon-dev-return-28278-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 42169 invoked by uid 500); 14 Jun 2002 15:54:43 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 41939 invoked from network); 14 Jun 2002 15:54:41 -0000
From: "Per Kreipke" <per@onclave.com>
To: <cocoon-dev@xml.apache.org>
Subject: RE: Cachability (was RE: XInclude Transformer vs CInlude Transformer)
Date: Fri, 14 Jun 2002 11:56:55 -0400
Message-ID: <FCEPLAOECPOAGINFDFCHOEOPFHAA.per@onclave.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
In-Reply-To: <GMEBIBHGAOFGJCDPJANDAEDGEJAA.cziegeler@s-und-n.de>
Importance: Normal
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

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.

<snip>

> > 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.

Per


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org