Re: storeGet() -> storeGetPublic() ?

On Mon, 8 Jan 2001, Adrian Chadd wrote:

> So, why not just make digest building part of the FS?

I think this is a design issue. Both FS-based and global-hash based
designs are possible to implement. Which one is the best? IMHO, it
depends on what Squid is (or supposed to be):

* If Squid should be highly optimized using a very specific low-level
architecture (e.g., reiser-fs), then digests can be merged with FS
level. When one is striving for the "last mile" of optimization,
everything tends to be "integrated". In the extreme case, every new
protocol can be supported by adding an extra spoon of spaghetti.

* If Squid should be a portable, general-purpose, "reference
implementation" of a cache as well as a playground for new caching
ideas, then, perhaps, low-level optimizations with side-effects should
not be allowed to take over the rest of the code. That is, cache
inter-communication should remain separate from storage module. In the
extreme case, if the next level of optimization requires merging of
logically-separate modules, that level of optimization should not be
allowed.

I might sound like a broken record, but I still think it is better to
define the ultimate goal before talking about specifics. IMHO, a
single piece of software cannot be everything to everybody, no matter
how modular the design is. Programs have "nature-coded" limits (at
least programs that cannot modify themselves :).

$0.02,

Alex.

P.S. My personal feeling is that 90% of performance can be achieved
     using the second (generic) approach. Adding FS modules may be the
     right direction. Reducing in-memory per-entry info may be the
     right direction. Implementing portions of cache communication
     protocols inside FS modules smells trouble to me.
Received on Mon Jan 08 2001 - 22:58:43 MST