Re: squid rewrite

> From: "Miguel A.L. Paraz" <map@iphil.net>

> work on push caching for the moment since it'll be a core part of the
> new Squid, if it is indeed adopted. I like the idea that different
> functions are distributed across different servers; that's very good
> for scaling up the service by just adding more boxes.
>
> I can imagine a cluster of Pentiums/PPros on a switched 100 MB Ethernet
> handling the load of a DS3, and when the load gets high, just add another
> machine and let the controller know about it without shutting down the
> service.

    Apart from providing non-stop service I can see more tightly managed
 cache hierarchy that gives much better hitrate and distributes load
 between boxes.

> I was also thinking of how do the others do it... like for example
> the commercial Harvest, what's it up to right now... and Mirror Image,
> too.

    I seem to recall similar problems and ideas from other vendors too.

> So where do we start coding? :)

    Before any coding, Duane and others in direct responsibility of squid
 development should have their last word, I guess. For now, IMO the best
 to do is to discuss agressively all possible pros and cons to come out
 with something semifinal.
    
 BTW, there have been many times thoughts about Squid File System. Every
 time I have seen these, it associated in my mind with a phrase Squid
 Operating System. Not that any of these ideas could/would be practical
 in near future, but any OS involves some sort of instrumentation, strictly
 dividing code into "user hacks" and "kernel hacks", and some standard
 interfaces between these. Shortcuts are cool (like direct mem-structure
 manipulations) but may become real nightmare when some design changes
 are applied. Maybe its a right time to standardise squid's procedures
 and document its core, insist on use of procedures instead of directly
 manipulating public structures. Just a thought..

 
 Andres Kroonmaa,
 MicroLink Online
 vorguadministraator.
Received on Tue Jul 29 2003 - 13:15:41 MDT