> 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'd agree with that. >> 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 :-). Yes, that works. > >> 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? Some, but not a lot :-) I'm constantly encountering syntax and typo errors because HTTP is not always spelt upper-case in class names. > > 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. Yes on both counts. its a big change, but big changes and goals are what we are about these days. Working up to it slowly would be fine, with a better definition of where and what before any code goes in, but I think it should be one of the end-goals. > >> 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. Meybe yes, meybe no. I haven't seen enough C++ code in /usr/* to judge it properly by. Amos