Inspirations

Too many reports from the trenches that half the maintenance time is spent in the configure/build/package/deploy process.
Rumors of Better Ways to do it (Scons, Rails Web Development, ...)
Too many hand-coded rote transformations of arguments from babel to native.
Every other middleware has needed and developed some sort of Component IDL that goes beyond SIDL to represent details of the CCA design pattern.
XML is great for .cca files read by computers but is too much for humans to create unaided.
XML adds a significant dependency (.scl, .cca) to the cca and babel tools at runtime.
In the wild, in most cases, the fundamental unit of development and deployment has been a project, (set of components), not an individual component.

Approaches

Go lighter on the parsing: use something more specific than xml and a set of parsers written in ANTLR but generated in C to eliminate heavy XML libraries or scripting language dependencies.
Define a grammar for describing the CCA-ness of components (what ports are provided and how).
Define as many conventions as we can, but make them configurable in a rails-like way.
Define a Babel AND Adjunct Impl Development (BANDAID) tool complementary to babel that employs argument transformation recipes.
Assume that babel will continue to support the autotools nightmare and thereby save the rest of us all the trouble of finding out which compilers and flags are in use.
Define tools and formats that ease the maintenance of component code without requiring Eclipse.

Requirements

This section is divided into several pages. The aim at this point is to define \\what\\ information we want to capture, not the format or particularities of how we capture it, parse it, or construct processor/generator tools that depend on the information.

MappingImplToTheExpectedNative - A Mitten (the CCA improvement over swig typemap) lets the component/project developer customize the mapping of babel-generated method arguments/exceptions/returns to their expected native impl, leaving only the computational logic to be generated manually. Of course there are many possible mappings, so you'll need Mittens to work with Babel on large projects.
ProjectsAsComponentCollections - Generally there are project or developer scoped information, like where cca-tools was installed and where the default config (think rails environment file if you are Rob) sits. What is it?
ProjectsAsBuildInformation - What do we need to extract from cca-spec-babel-config and from the user when building?
ProjectsAsInstallInformation - What do we need to extract from the developer and what from the deployer to install/uninstall correctly?
ComponentsAsPortCollections - Lots of cca-usage errors can be prevented by following (and automating) conventional use of the Services interface.
PortsAsSIDLCollections - We'll be referencing SIDL interfaces (port and non-port) and dont' want to create another SIDL parser if we can avoid it.

Implementation notions

ProjectCommandLineErgonomics - What should the command lines look like? Bear in mind that since it's the unix shell, more than one answer is allowed.
ProjectEnvironmentFileFormat - How many different ways can we represent the required information? Is XML always the answer?
PerComponentFileFormat - Grammars or key-values for describing CCAness?