[ccan] A few questions about ccan

[Rusty Russell]

On Wednesday 25 February 2009 15:46:44 Stephen Cameron wrote:
> Is the emphasis of ccan seen to be on the "comprehensive" part, or, on the "archive" part? 

Good question :)

> Or to put it another way, is ccan primarily yet-another-packaging-scheme?

There's two parts: junkcode (if you upload C code it goes here), and actual
modules which have an _info.c file (ie. metadata) and tests.

> There are obviously a lot of libraries and such which can be had via "yum install xxx-devel" or "apt-get install xxx-devel" and source is typically available through apt-get and RPM/yum as well. (though RPM/yum and apt-get are obviously OS-specific).  Is the expectation that these sorts of things would be additionally packaged as ccan modules?

At this early stage, we're not dictating what will and won't go in; I'm happy
to see where it leads us.

Some things work quite well as libraries: they're widely used and have fairly
fixed interfaces (eg. libz).  But there's a whole heap of code which simply
isn't: this realm is filled by example code or extracting files from existing
projects and hacking it to fit.

There's also an opportunity to get a community who agree on best practice,
as well as the minimal levels of uniformity needed to make a module "drop
and go".

> Or is the long term view that the "comprehensive" aspect of ccan would some how provide an index of that sort of thing, rather than an additional copy packaged a different way, the ccan way?

I pulled in (a version of) talloc, for example, because I wanted it for other
modules and I needed to make enhancements for shared memory.  I pulled in tap
because it was abandonware.  In both cases, I'm maintaining the ccan versions.
I wrote antithread from scratch, and put in in CCAN because it seems like a
good place to live (it uses other ccan modules).

If someone sees ccan as a good place for their library to live, great, but
pulling in existing libraries for the sake of it doesn't seem useful.

> Or is ccan more focused on smaller hunks of hackable C source, and less on "libraries"?

Small hunks of excellent code are more attractive to *me* because I want
to have a place I can pull them from easily.  But others will surely add
libraries, even utilities, so that might end up being the minority.

> Just wondering, and hope my questions make sense.

They make sense!  I'm just not sure we know yet; ask in 5 years :)

Cheers,
Rusty.