Davi Arnaut wrote:

It's a design flaw to create problems that have to be specially coded around, when you can avoid the problem entirely.

Maybe I'm missing something, what problems do you foresee ?

There are lots of issues that were uncovered when I split the proxy and cache code for httpd v2.0.

A web cache requires two separately alterable cached entities (headers, body) just for caching a single variant. This pair of entities need to expire and/or be forceably expired (think Cache-Control no-cache) atomically. Sure, you can code and debug a lot of code to try and create the effect of atomically expiring multiple cache entries at once. Or you can avoid this issue entirely by building a generic cache that works with key/subkey/data.

There are a number of other issues that have been listed as bugs since httpd v1.3 that are still present, most notably the thundering herd problem, and the independent caching of variants. There is no point in refactoring the cache code if the new code isn't going to be significantly better than the existing code.

Regards,
Graham
--

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to