Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3FDF654D.6000308@leverageweb.com>
Date: Tue, 16 Dec 2003 15:04:29 -0500
From: Geoff Howard <cocoon@leverageweb.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Accessing cache validities from flow
References: <264DFACA-2FA5-11D8-8A39-000393D2CB02@apache.org>
In-Reply-To: <264DFACA-2FA5-11D8-8A39-000393D2CB02@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Stefano Mazzocchi wrote:

I also am long on interest, short on time right now but I'll chime in below.

...


> the problem is that since the file 
> system is such a stupid repository, 

OT: I have looked into experimenting with the filesystem event 
notification built into some operating systems (windows and linux both I 
think) to trigger file system "events".  If anyone good with native code 
and JNI wants to play, it'd be a cool experiment.  Non-portable 
unforunately.

...

> Now, the way the event cache works is like this:
> 
>  a) a cache validity is generated
>  b) pipeline is executed
>  c) result is stored in the cache
> 
> then the pipeline is never called, until an event is triggered 
> externally (from an avalon component) that invalidates that particular 
> cache entity.
> 
> Now, the problem is: if I am not the one who generates the validity (in 
> linotype, it's the directory generator), how can I invalidate it? how 
> can I have access to it?

I'm not sure I'm correctly interpreting the problem as you state it.  If 
directory generator were made "event aware" either by using the validity 
delegating generator Unico mentioned or by some new pipeline-level 
pluggable "Cache Strategy" (which I've wanted to look into) that would 
be a sort of known contract.  Currently the two EventValidity impls are 
brain dead and so the method for creating an event is vague because I 
wasn't sure if anything more than this would ever be needed.  One could 
imagine a "FileSystemEventValidity" which uses some internal logic for 
constructing the proper validity.  Does this not get at the problem?

Now, one problem I never solved related to the file system specifically 
was how to do what I thought of as "wild card" events.  In a file 
system, if your validity is built on /dir/to/your/files/myFile.xml and 
you delete the entire /dir/to directory tree how do you fire that event? 
  With the current design, you'd have to either fire off an individual 
event for each file under the deleted tree, or come up with some magic 
for handling an event like /dir/to/*.  Because the event lookups are 
handled by Hash based collections, which rely on hashCode() and equals() 
  you'd have to examine every event in turn to see if it matched the 
wild card.  I'm sure there is some brilliant solution to this but it 
hasn't occurred to me yet. ;)

> I'm starting to think that the cocoon cache needs a serious redesign to 
> deal with these issues... and this scares me :-( but it's *waay* too 
> important to let go.

Well, spill the beans - what do you have in mind?

Geoff