Re: snapshot available

Dancer wrote:

> Excellent. This gives us something to hack on without getting too far
> out of synch.

I already am way out of sync. My diff to 2.1.DEVEL3+ is about 100KB, and
that is without a full configure diff, and It's a pain to maintain all
patches.

I would wery much see that these snapshot releases are made on a regular
interval, to quickly catch up on what has been commited to the head, and
how.

> I've been thinking about:
>
> * DNS (the brief discussion we had about it, and Henrik's comments)
> * IP protocol independance.
> * Past discussions with Alex about modularity.
>
> I definitely want to look at how you did the DNS stuff. If it's modular
> enough, I may be able to drop in IP protocol independance as an
> alternative source-module. Otherwise, it could be hacked on until it
> _is_ modular.

It looks kind of modular in design. The API is only 4 well defined
functions (Init, Shutdown, AQuery, PTRQuery). Only critics is the
input/output types should be adjusted to struct sockaddr rather than
struct in_addr. This transition should be done all throught Squid, to
abstract it from IPv4. struct sockaddr is the only commonly available
abstract address data type.

> I'm coming to agree more and more with Alex's standpoint on
> modules-not-conditionals.

The major part in implementing a modular design is to design the proper
module interfaces. The store I/O is a first step to this.

> Curious: Have we thought about dynamic shared objects (ala apache)?

The idea is nice, but FIRST we need to design the module interfaces.
There is no point in building shared objects if there is no defined
interface the shared object implements. Squid won't be more modular only
because certain parts are shared objects, if these objects can't easily
be replaced by another object implementing the same interface, and
implementing a replacement requires one to be able to know what is
expected of the interface.

I think this is an issue for Squid Version 3, which in my opiniton
should be a major redesign from ground up with well defined module
boundaries. The current codepase is a bit to messy to start from (a lot
of things can be reused of course, but only after a proper interface
design phase).

Things that defenitely should be isolated in modules
* Client code, all code involved in reading or writing client
filedescriptors
* Store manager
* Store filesystem
* Protocols
* Special methods that require special handling (PURGE and TRACE are two
examples).

/Henrik
Received on Tue Jul 29 2003 - 13:15:58 MDT