Re: squid3 future directory structure

> Hello,
>
> I have created the following wiki page to see if we can agree on how
> to define future subdirectories and what to move there. This can be a
> Squid 3.2 feature, I think.
>
> http://wiki.squid-cache.org/Features/SourceLayout
>
> Amos, do you want to lead this activity? I have already covered about 75
> files out of 284 in src/ (not counting the differences in extensions) to
> bootstrap the process?
>
> Thank you,
>
> Alex.
>

Added ICMP to your list of components. It's a clear-cut one now.

As to your questions. I think:

1) Should we use squid/src/squid/ root for most sources to include header
files as <squid/group/file.h>? This may be required for installed headers
and 3rd party code using those headers.

I'm undecided on this one. Lack of info to base the decision on. It will
really depend on the descision of whether or not to publish the headers
for external use.
I am inclined towards the publishing, but not towards the squid/src/squid
hack we need to do.

2) Where to put OS-compatabilities wrappers that are currently located in
squid/lib and squid/include?

I like them where they are. It's the extras that have been added there
(guilty!) and the mixed styles of compatibility coding that are confusing
things.

The schema I have been working to for these is that if a system library
function has been replaced or added for compat. It has a name starting
with 'x' (extended!) for use in the general squid code and a header file
that has:

#if its-not-needed
#define xFoo Foo
#else // its needed!
void xFoo(...);
#endif

That makes for slightly smaller code and clearly just an alternate version
of the library call. Developers can use the xFoo knowing it has the same
behaviour and pre/post-conditions as can be found anywhere online. BUT, an
implementation that works better in squid.

I'm sorry Duane, but the use you seem to like of adding "Squid_" brings to
mind more of 'completely re-written for squid, with different behaviour or
usage' function.

3) Where to put 3rd party libraries that are currently located in
squid/lib and squid/include?

./src/dependancies/ ??
./dependancies/ ??

Definately split from the compat files though.

4) Can we remove Foo prefix from FOO/FooSomething.h file names? The prefix
carries no additional information and is probably not required for modern
compilers, especially in C++ world.

I'd prefer the filenames matching the (single!) class defined inside.
Standard C++ practice for some. That means some need a Foo/FooX others
just Foo/XYZ.

5) Should client- and server- side files be separated?

I think so. The combination is whats most confusing to me in squid at
present. Identifying what file changes impact what side of the
transaction.

6) Should directory names use just_small, CamelCase, or CAPS letters?

I Think CamelCase like we do for files and classes, with acroynms being
upper case is working. When we can make the converted and re-used legacy
files from lower-only to CamelCase it will sit better than now.

That said, this may impact the /usr/local/include descision. I think there
is some tradition of lower-case with underscores on most OS.

Amos
Received on Wed Feb 13 2008 - 15:45:22 MST