[reSIProcate] RE: Caching Control
The first pass was going to be always cache, as ares doesn't do any caching
and the cache size was going to be configurable. It will easy to have the
same code not cache. Since the external dns provider is selected at compile
time this prob. won't be a run time flag right away, but that won't be hard
to add.
Blacklisting will work w/out caching and will prob. we realized as a filter
that sits on top of the "optionally caching" api.
--Derek
> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks@xxxxxxxxxxx]
> Sent: Tuesday, March 15, 2005 11:19 AM
> To: Alan Hawrylyshen
> Cc: derek; resiprocate-devel@xxxxxxxxxxxxxxxxxxx; 'Scott Godin'
> Subject: Re: Caching Control
>
> agreed.
>
> I'm ok with the presence of the layer being a ./configure option for now
> if that's the path of least resistance.
>
> In the long run, I'd like it to be something you control at runtime.
>
> RjS
>
> On Mar 15, 2005, at 12:41 PM, Alan Hawrylyshen wrote:
>
> >
> > On Mar 10, 2005, at 17.24, derek wrote:
> >
> >> The caching will run on top of DnsInterface&ExternalDns, which is the
> >> abstraction that hides ares. It won't even know /etc/hosts exists; I
> >> think
> >> we'll have to fix ares.
> >>
> >> --Derek
> >
> > Whatever the solution we arrive at for the Cache and Blacklisting (or
> > weighting), the abstraction MUST support a NULL Cache implementation
> > (which should be done just as a POC) so people who don't want caching
> > can still compile the stack.
> > We definately want to cleanly separate the cache from the weighting it
> > at all possible, otherwise we're getting into a very complicate mess
> > potentially.
> >
> > Thoughts?
> > Alan
> >
> > a l a n a t j a s o m i d o t c o m