Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of renyedi@gmail.com designates
 64.233.182.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=HBNSUFnvGAWsdhn5UvmquRopDnXYtEoFy/1CSl4MNmkJmF2MQAaf9FVGTXbkryGZMisSMuApzTXHjq+5+MgSL9wdH5tXsIX2TK9Z/T2a3zV7KXU6Ry9wHpEy3FzwRMnZXLf+tM7waujxCulOwJfiPQ1+lDTqQ2sUCr1RWSvNPY0=
Message-ID: <2e67829d0603300516q65d31402me4c74fbaa7c5ca51@mail.gmail.com>
Date: Thu, 30 Mar 2006 15:16:43 +0200
From: "Robert Enyedi" <renyedi@gmail.com>
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Subject: Re: [VFS] cache on children
In-Reply-To: <442BC634.4040800@ops.co.at>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_4199_3004057.1143724603262"
References: <442BA430.8000404@sophia.inria.fr> <442BA6F6.7040404@ops.co.at>
	 <2e67829d0603300336j631a0a82s6e5aa0958bfdbe8a@mail.gmail.com>
	 <442BC634.4040800@ops.co.at>

------=_Part_4199_3004057.1143724603262
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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

------=_Part_4199_3004057.1143724603262--