commons-user mailing list archives

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 <mario@ops.co.at> 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: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>