Re: snapshot available

Henrik Nordstrom wrote:
>
> 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.

Amen. I've been holding off doing code work because I'm aware that the
code is a moving target, and I don't want to write code that'll have to
be rewritten twice or thrice before it actually meshes with the
source-tree.

Although I will if I have to.

>
> > 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.

What about if I wrote portable addrinfo code (in case it is unavailable
on any given platform) and pass addrinfo structs instead of sockaddrs?
Got a big book with an implementation, after all.

>
> > 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.

Well, we can do it stepwise. Allow modules to actually be supported
first (loaded and called), and then start abstracting existing code into
'default' modules. That way we'd only have to focus on one area at a
time, and could talk it through before committing to an API.
>
> > 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.

Agreed. Ref above comment, though. I don't think we need to thrash out a
whole mess of API's at once. In fact, I think we'd do a better job if it
was piecemeal...we'd learn from mistakes as we go before we'd have gone
too far down the road.

> 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).

Methods (yes), peer-selection algorithm, expiry algorithm.

The way I see it, we wouldn't have to support the huge module-chaining
effort that (eg) apache does. Since some things don't make sense chained
together. One expiry algorithm is pretty much mutually exclusive vs
others. Same with the store-filesystem, IMO.

(Hmm. You used store-manager where I said expiry alogirthm. I think
we're essentially talking about the same unit there.)

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