Date: Tue, 26 Aug 2008 02:23:01 +1200
Okay, got the pretty-picture drawn up.
NP: this is drawn up as a high-level flow from my accumulated view of
all our work to date and where its heading. That includes Adrian's
Squid-2 work and where I see it most efficiently mapping into Squid-3.
It should be very similar to how squid currently works. With a few major
differences that we have all spoken and planned things around already.
1) Data Pump side-band. This is a processing-free 'pump' for any
requests which do not actually need to go through Squid's twisted
logics. With all logics compiled out it should be equivalent to a NOP.
But can be used by things such as adaptation components as an IO
abstraction.
2) Client Facing IO is unwound from all processing logics. It's simply a
raw input layer to accept connections and interface to the clients.
3) Server Facing IO is likewise unwound from processing logics AND from
client IO logics. Though in reality it may share lowest level socket code.
4) Processing components are distinct. Each is fully optional and causes
no run-time delay if not enabled.
5) Stores are an optional extra, if the configuration calls for caching.
But not needed for basic operations.
If we all agree and work towards this type of model and things are kept
modular isolated to the highest levels. I don't see the future
integration of either squid branch or CacheBoy as being a big task.
Amos
