Re: modules

Dancer wrote:

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

At nearly all locations the port number is interesting as well and today
kept at a separate location(s). The DNS interface is about the only
exception to this rule.

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

No problem with that. I was only trying to steer the discussion away
from shared vs static objects to instead discuss what should be
modularized and with which interface. The switching between dynamic vs
static modules is a piece of cake in comparisation.

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

We are most likely looking at isolating a certain functionality into a
module, not a generic modules design to fit all possible parts like
Apache. But then, again maybe we should atleast partially, but lets
leave that for later when we have a better idea of how Squid can be
broken into separate modules.

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

We do, except that the expiry algorithm is only part of what the store
manager implements. There is also a lot of functionality to support the
expiry algorithm, like the maintaining a linked lists sorted on LRU for
the LRU implementation. Some exprity algorithms put very specific
demands on the store manager.

If your read my last message I thinks of the store as a three layer
thing:

(* Store key generation, currently MD5 hash of the method and URL)
* Access methods for storing/retreiving objects based on their key.
* Internal filesystem I/O implementation
* Store maintenance, implementing store expiry/recycling and the like.

The access methods most likely are part of the core store manager, but
both filesystem I/O and mantenance can be separated into replaceable
modules.

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