httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <ab...@dial.pipex.com>
Subject Re: Small direction change for APR's file I/O routines.
Date Tue, 11 Jan 2000 10:23:15 GMT
That looks like a good idea.  Apologies for earlier misunderstandings...

d.
----- Original Message -----
From: <rbb@apache.org>
To: <new-httpd@apache.org>
Sent: Tuesday, January 11, 2000 2:18 AM
Subject: Re: Small direction change for APR's file I/O routines.


>
>
>
> > > Or, I have seriously had three or four people tell me that they really
> > > want to have APR provide a stat cache for them.  I really don't care,
but
> > > if enough people continue to ask for it, I will put it into APR.
> >
> > I'm with Dean on this one: I don't think a library can always do a great
> > job of it. The application knows best about its behavior -- when/why it
> > calls stat(), when it should purge, how big the cache should be, etc.
> >
>
> Obviously I need to do one of two things.  Either never speak about
> possible future enhancements to APR, or explain them in detail whenever I
> do.  :-)  This wasn't meant as a "I'm doing this tomorrow" kind of thing,
> but I figure I'll quell this now since I brought it up.
>
> I have had a couple of people express the desire for a stat cache in APR,
> this does not mean APR will manage the cache, it just means APR will
> provide the functions necessary to do the cache management for you.  It
> doesn't even have to be limited to a stat cache, it could conceivably
> cache anything.  For example, why should the base Apache, and mod_proxy,
> and mod_php, and mod_perl all have cache code in them?  For the most part,
> a cache is a cache what is being cached changes, how long it should be
> cached for changes, but the basic operations remain the same.  Let me give
> you an example of the API I was considering.
>
> ap_initialize_cache(ap_cache_t *thecache, int num_elements, func
> *cleanup_routine, ap_context_t *cont);
> ap_add_element(void *elem, ap_cache_t *thecache, int timeout);
> ap_get_element(void *elem, ap_cache_t *thecache);
> ap_free_cache(ap_cache_t *thecache);
>
> This is not a set API, there isn't even ideathing saying this will ever be
> implemented, but the idea of APR providing cache'ing functions is the same
> as APR providing queue'ing functions.  These are portable, and it doesn't
> make any sense for every program to write them again.  It would even be
> possible for programs to compile APR without having these functions be
> provided.
>
> I will not be addressing the stat cache or cache'ing issue again, because
> it isn't really important to Apache right now, it has nothing to do with
> Apache 2.0, and I never should have brought it up.  But, providing basic
> routines like this is a good thing for APR to do, IMO.  I know mod_proxy
> needs a cache, and I know mod_php and mod_perl already use a cache, IMHO,
> it should be the same code, and it isn't currently.
>
> > The library just can't know all this.
>
> And, as I just explained, the library doesn't have to know any of it.
>
> Ryan
>


Mime
View raw message