Re: modules

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

The port number is probably the simplest piece of the assorted network
parameters to deal with seperately. Dummy addrinfo structures with port
0 and plug in the actual port later (before passing to connect). v6 and
v4 share port space, so it's not actually in any way critical, and in
fact is the easiest one to skip over.

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

Concur.

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

Gotcha. It's nice to have the same set of definitions. Hmm, and yes. I
can see how to abstract the filesystem interface, and the others. At
least an outline wanders into my head.

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