< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] RE: Caching Control


Hi Alan,

Maybe you can take a kick at adding in the configurable support for
enabling/disabling the cache once Derek gets his stuff in place.

Jason




On Tue, 15 Mar 2005 12:05:41 -0800, derek <derek@xxxxxxxx> wrote:
> 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
> 
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>