Re: squid3 future directory structure

On Thu, 2008-02-14 at 11:45 +1300, Amos Jeffries wrote:
> > http://wiki.squid-cache.org/Features/SourceLayout

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

Thank you. Can you lead this activity? We need somebody who will drive
the discussion and oversee actual changes...

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

Yeah. I posted a separate message on eCAP that has an alternative to
exposing Squid headers and libraries. Perhaps that would work better.

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

I do not like the generic says-nothing names "lib" and "include". I also
do not like that the two directories pollute the top-level directory.
Can we, perhaps, agree on something like

        squid/compat/include
        squid/compat/lib

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

The problem with "xFoo" is that other libraries we link with might have
their own "xFoo".

A C++ solution for this is namespaces, I guess, but it would require
more work to implement that approach in a clean way.

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

How about

    squid/import/

It is more specific, shorter, and easier to spell :-).

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

Any chance to convince you and others that HTTPReply is not as readable
as HttpReply?

If we start using namespaces for protocols, then this becomes a
non-issue because HTTP::Reply reads just fine. Perhaps this should be a
separate question. Should we start using namespaces for protocols and
other important groups? I think we should.

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

I am not sure that tradition applies to C++ stuff or "modern" code in
general.

Thank you,

Alex.
Received on Thu Feb 14 2008 - 09:26:14 MST