10 is now enshrined in approved process docs.
 9 is now done.
 8 The topic of exceptions, what kinds there are, and how they
   should be distinguished is fine. The principal argument for bringing it
   up (which is that an enum is somehow "not OO enough") is misplaced
   in that only 1 of the N languages supported with the CCA
   specification feature a "natural enough" casting/ex.catching mechanism.
   (I have evidence for that statement resulting from bocca).
   Indeed in over half of the languages, (c,f77,f90,python) catching/casting is
   downright painful. The idea of rederiving CCA exception from
   one of the sidl bases merits consideration-- it's a hole in
   the spec that user code cannot create and throw a ccaexception
   within the specification (currently) unless they do a full
   implementation of the ccaexception specification.
 7 Event, option processing (commandline) and mpi service.
   All now unblocked at ccarb step. just need to schedule them
   through the process.
 6 Queueing on 7.
 5 Where to begin:
   - The specification already supports BasicParameterPort (Just 3 functions).
   - Tutorial-style app examples have been created and posted
   for both PP and BPP in f90 and c++, and they are not that complex.
   - Having many functions in the spec makes for fewer, more precise calls
   being needed in the application code.
   - Ccaffeine has been brought into compliance with BPP; I suggest this
   issue be closed unless there is concensus that CCA should be
   investigating the "bean" pattern of getters/setters from java; now
   that bocca exists, beanism would be feasible to support.
   - The metric of "function count" as shown in the PPT is *exactly*
   what one expects (and sees) in any data-holding interface; cca
   TypeMap has roughly 2N functions (where N is the number of sidl
   primitives supported). ParameterPortFactory adds another 2N functions
   that serve to set and query metadata (help, string name, bounds, etc
   about the elements of a typemap). We are dealing with multiplicity
   of primitives, not vast complexity.
 4 Already done. What is needed is documentation.
 3 A sidl file is not a specification for human consumption. The cca
   sidl file should be
   an artifact that can be generated from a specification for humans.
   I suggest that open-source specifications for humans are produced
   with tex. All Gary's comments about inconsistencies and other nits
   are very well founded. Where the inconsistencies are in the comments
   not matching the argument names on methods, I have tried to make the
   comments match the methods when I notice it.
   SIDL, even with proposed contract extensions, is not sufficient to
   specify software behavior of the sort required in the CCA
   specification.
 2 All the proposed words (interoperability, compatibility) as proposed
   imply babel/sidl conformance directly. This is a non-starter for
   many. However, for at least the babel case appropriate testing
   for compliance could begin as soon as a real specification document
   is written.
 1 The manual, if one wants to call it that, is already in progress in
   the form of documenting bocca and its uses. Queueing on the spec
   being finished.