[ccan] CCAN issues

[Michael Cohen]

Hi Rusty,
   Thanks for taking the initiative...

> 1) Domain name.  ccan.org would be ideal: seems to point to a generic ISP
>    page, whois says Community Care Ambulance Network in Ohio, which seems
>    legit at first glance.  ccan.com seems to be for sale by a squatter,
>    perhaps we could do some deal where we buy ccan.com for the ambos and get
>    ccan.org?

What about ccan.com.au? or maybe a hyphenated version (ccan-repo.org
for example?)

> 2) Namespacization.  If someone can't use (say) container_of because their
>    existing project uses that name, it'd be nice to rename it to
>    ccan_container_of.  Of course, this means any other ccan modules which use
>    this need changing too.
I wonder if that is an integration issue? Clearly linking in C will
become an issue due to name clashes. We should aim to have all ccan
modules linked internally with strict symbol exportation controls
(most things static etc). Things like macros and exported functions
will need to be prefixed by something. (maybe ccan_ ).

>    I thought about making the ccan_ versions canonical and providing macros
>    to map to the normal names, but it breaks the golden rule:
>
>         This code must not be ugly.
>
>    So I chose the harder road of supplying a C program to actually rewrite the
>    module and anything which depends on it.  Not quite finished yet, but it
>    has the merit of placing the burden of ugliness where it belongs.
This might produce un-ugly code but would make it difficult to
integrate future versions of ccan into your project. This is because
the version in your project would be different than the version in
ccan and its hard to track these differences. I think it would be less
ugly if the user ultimately drops in newer versions of ccan files
instead of having to re-generate them.

> 3) Minimum compiler requirements.  Seems like Microsoft's C compiler doesn't
>    do vararg macros, let alone any other C99 stuff.  This makes it impossible
>    to have nice code for some things, so for the moment I'm still sticking
>    with my intention of requiring (most of) C99, and Windows coders will have
>    to hope they catch up, or we do some horrible mangling at the user end
>    (like namespacization).
I dont think thats a great issue since gcc is also available for
windows - I somehow dont expect hard core windows coders to be using
ansi c (if they use MSVC they are more likely to use c++).

> 4) Licensing: so far I'm restricting it to with BSD no advertising, or GPLv2+.
>    More than that makes life too tricky for people wanting to use the code.
We need a consistant license for everything - unfortunately for
testing etc we our selves will be linking to our own code so if we
have a mix of licenses we might be breaking them ourselves.

> 5) Uploading, automated testing, etc.  No idea here, plan to steal as much of
>    CPAN as possible for this.
I think we need to use something bzr or darcs where people can send
patches to the maintainer. These need to be tested before added for
inclusion into the repo. There need to be some requirements before a
module goes in (like tests, license etc).

> 6) I have documentation-extraction code, but it doesn't do any xml-style guff
>    (the Linux kernel's system on which this is loosely based is perl based, so
>    maybe we should just steal that for the documentation, as it does various
>    different output forms).
I personally dont like automated documentation generation - most of
the time it tells you exactly what you would be able to read by just
looking at the code and it allows people to be sloppy about writing
documentation (hmm i can just run doxygen on this later - no need to
document). I think reams of doxygen generated code from a thinly
documented source tree is worse than do documentation at all.

> 7) Automatic downloading, testing, checking for updates, and dependency
>    tracking.  This would be nice, particularly handling namespacization and
>    detecting local mods.
Again bzr of darcs can automatically take care of the updating,
dependency tracking and detecting local mods.

Michael.