My apologies for the delayed mails, I'm having some troubles sending "From: <a href="mailto:adamk@cpan.org">adamk@cpan.org</a>", so I've switched over to a pure gmail account for now.<br><br>I'll make some quick responses at the moment, but I'd just note that we need to be VERY careful what underlying choices we make for what the CCAN becomes. Scope and constraints make or break whether this stuff works in the long run.
<br><br><div><span class="gmail_quote">On 18/12/2007, <b class="gmail_sendername">Rusty Russell</b> <<a href="mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
OK, so I promise I'll put up a bzr repo sometime soon, but meanwhile here's a<br>list of thoughts on open issues in no order:<br><br>1) Domain name. <a href="http://ccan.org">ccan.org</a> would be ideal: seems to point to a generic ISP
<br> page, whois says Community Care Ambulance Network in Ohio, which seems<br> legit at first glance. <a href="http://ccan.com">ccan.com</a> seems to be for sale by a squatter,<br> perhaps we could do some deal where we buy
<a href="http://ccan.com">ccan.com</a> for the ambos and get<br> <a href="http://ccan.org">ccan.org</a>?</blockquote><div><br>I'd say do whatever we can to get the best possible name, it makes a huge difference.<br>
<br>The JSAN (JavaScript Archive Network) ended up going with <a href="http://openjsan.org">openjsan.org</a>, although after putting in some time I did have an option to get <a href="http://jsan.net">jsan.net</a>, which would have been preferable but was overruled because getting a domain was always "done".
<br><br>Lets find someone from Chicago and make contact with those guys.<br><br>Or perhaps we can use <a href="http://ccan.com">ccan.com</a>? or <a href="http://ccan.net">ccan.net</a>?<br><br>Using a domain for any specific country it out, as these projects are always global in nature.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2) Namespacization. If someone can't use (say) container_of because their
<br> existing project uses that name, it'd be nice to rename it to<br> ccan_container_of. Of course, this means any other ccan modules which use<br> this need changing too.<br><br> I thought about making the ccan_ versions canonical and providing macros
<br> to map to the normal names, but it breaks the golden rule:<br><br> This code must not be ugly.<br><br> So I chose the harder road of supplying a C program to actually rewrite the<br> module and anything which depends on it. Not quite finished yet, but it
<br> has the merit of placing the burden of ugliness where it belongs.</blockquote><div><br>This part is tricky, and I'm not sure there's much I can do to contribute, since I'm not experienced in this area. But I'll talk more a bit later about these sorts of issues (I'm up to my eyes in Perl
5.10 release stuff for another few days).<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">3) Minimum compiler requirements. Seems like Microsoft's C compiler doesn't
<br> do vararg macros, let alone any other C99 stuff. This makes it impossible<br> to have nice code for some things, so for the moment I'm still sticking<br> with my intention of requiring (most of) C99, and Windows coders will have
<br> to hope they catch up, or we do some horrible mangling at the user end<br> (like namespacization).</blockquote><div><br>As a general rule, dealing with commercial programs is hell.<br><br>Strawberry Perl demonstrates a precedent for using MinGW and (in our case, for some specific legacy reasons) dmake to build various stuff.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">4) Licensing: so far I'm restricting it to with BSD no advertising, or GPLv2+.
<br> More than that makes life too tricky for people wanting to use the code.</blockquote><div><br>This is going to be one of the more complex and unique elements of this project, because we haven't hit it with either Perl or JavaScript, we may need some help from legal counsel.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">5) Uploading, automated testing, etc. No idea here, plan to steal as much of<br>
CPAN as possible for this.</blockquote><div><br>These are non-issues for now. The various elements of the CPAN "cloud" of services are written and owned independently and were created after and around the core.
<br><br>In particular, you should completely ignore things like documentation websites, automated testing and quality control and so on for now.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
6) I have documentation-extraction code, but it doesn't do any xml-style guff<br> (the Linux kernel's system on which this is loosely based is perl based, so<br> maybe we should just steal that for the documentation, as it does various
<br> different output forms).</blockquote><div><br>The only thing I'd not on this topic is the Perl code this part completely right.<br><br>By convention, the docs don't just show function/method details, they also have free-form description sections, allow samples in synopsis sections, and so on.
<br><br>They act much more like in-line man pages than API docs, and this has worked enormously well. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
7) Automatic downloading, testing, checking for updates, and dependency<br> tracking. This would be nice, particularly handling namespacization and<br> detecting local mods.</blockquote><div><br></div></div>Ignore automatic downloading, ignore testing, updates and dependency tracking. We aren't ready for that yet.
<br><br>The first two major elements we need to define is<br><br>1. The toolchain and methodologies on a per-package basis.<br><br>(Issues like libtap and which compilers we support belong)<br><br>2. The definitions for what the actual "products" the CCAN provides are.
<br><br>(Issues like cut-paste vs code munging vs libfoo distribution).<br><br>Once we have a rough handle on what a "CCAN package" is, and how it is structured and installed, the rest is either a) Irrelevant or b) Unscopable.
<br><br>Solving the wrong problems too early is a common fault of some of the worse repositories.<br>