On Thu, 22 Mar 2007 11:23:18 +0200 Graham Leggett <[EMAIL PROTECTED]> wrote:
> Helmut Tessarek wrote: > > > Caching: > > > > I've just changed my caching algorithm to use APR, so it must be > > fairly easy to either add caching to the DBD framework or to write > > its own caching backend. Regarding the modularity, an own autnz > > caching backend would be best. So all other expensive providers > > could benefit from caching. See http://tinyurl.com/yvwnhs for my Don't tinyurl references expire after a few days (or weeks or something)? Mailinglists, by contrast, are archived. I understand you may want to retain the flexibility to invalidate that link yourself, but a mention of the top of your repository at www.evermeet.cx/cvs/ surely wouldn't hurt? > > caching functions. It would be nice to even add memory caching > > functionality to it. If someone has any ideas, please let me know. > > I don't need to write all code by myself, so I would be happy to > > help out with it. That looks fairly generic now, thanks! > The LDAP authentication module has support for caching, it may be > worth investigating whether parts of it can be abstracted out into a > generic authentication cache. > > The LDAP cache already supports things like shared memory, etc - it > may be useful to use that existing code as a base rather than > reinventing it from scratch. IME the LDAP code tends to be rather inward-looking and isn't always the easiest to re-use (and util_ldap_cache.h lacks the prototyping and documentation of a public API). If you can find a round tuit for making that jump from specific to generic then great, but until then I think we should welcome alternatives into the ecosystem. This one has a simple, clean-ish API and looks pretty easy to work with. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
