Hi Mario, I like your proposal. It's simple and effective. But having option b) the default wouldn't break backward compatibility?
One thing though I don't understand. At option b), why call resync() _after_ the resolveFile() call. Should it be before? Regards, Robert On 3/30/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > > Hi Robert! > > Mario, I know that the caching mechanism has high priority for VFS 1.1, > but > > what if until than we would have a utility class > Fact is, that I should take the time to fix this annoying thing. > > So lets discuss what I have in mind. Basically your utility class is > something I had in mind, just a little bit more integrated into VFS. > > I would try to implement this in VFS using the decorator pattern. In the > end I wanted to have 3 caching strategies: > > a) manual - as it is now, but maybe provide a method called "resync()" > b) perResolveFile - resync() once directly after a resolveFile > c) perCall - resync() once before any method call on a fileObject method > - this is your utility class but as a decorator for the FileObject so > the user didnt see this - the downside here is that any "fo instanceof > ...." no longer work, but no one should be required to do this, and I'll > provide a helper class e.g. FileObjectUtils.instanceOf(fo, class) > > IMHO, version b should be the default. The caching strategy should be > configurable per FileSytemManager instance. > > WDYT? > > Ciao, > Mario > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
