Tasks

• Implement command handlers for common (all) bocca actions (Boyana and Wael) {added 3/8/07}
  • project creation and configuration
  • class/component creation, renaming, deletion, adding and removing uses/provides ports, implementing interfaces, extending classes (maybe)
  • interface/port creation, renaming, deletion
  • Current plan: use classes representing projects, interfaces/ports, classes/components and construct a dependency graph from the project state (stored in a file). Then use the visitor pattern for each SIDL entity (and project) to perform the different operations, e.g., create, remove, rename, move.

• Create a command dispatcher that does the right thing in the face of version changes, which means dispatches to a local copy of boccalib-$PROJ if it exists otherwise uses the system-wide installation. (Ben) {added 2/20/07, completed 3/8/07}.

• Investigate running Ruby over standard JVM — yes (Rob) {added 11/10/06, completed 11/16/06}

• Create shell script guidelines for the implementation (Boyana, Manoj) {added 11/10/06, became irrelevant 1/2007 since python is being used at the moment}

• Define the basic bocca interfaces {added 11/10/06}https://www.cca-forum.org/wiki/tiki-editpage.php?page=Tasks

• Merge individual bocca prototypes into a commonly developed project {added 11/10/06}

• Create a cca-config script interface and implementation that wraps whatever-config scripts for underlying software (babel-config, cca-spec-babel-config, ccafe-config, other frameworks) and is used by bocca {added 11/10/06}

• For each project, create and maintain project-config {added 11/10/06} — done in Rob's prototype Rob

• Determine the state data file format (options?). So far Wael and Ben have expressed a preference for key-value formats that are easily parsed in any implementation language. That this will be sufficient is not at all obvious yet. {added 11/10/06}
  • Boyana suggests the following initial format (if a value must contain commas, it should be quoted; embedded quotes are escaped with \). Keys are standard identifiers (letters, _, numbers,.). Values can be anything, and whitespace between tokens is ignored.

• This format is shell-programming hostile from the get-go. What is CSV in the values buying us? I can't think of a single instance in the current tutorial where lists needed commas. Also, why : instead of = ? Why not allow . in keys? -Ben
• There are, of course, regular expressions in shell scripts. However, I don't care what the format is as long as I can represent lists of lists; feel free to change the format above, it was just something specific to encourage changes. Just pick a separator that makes you happy. -Boyana

• Having spun the requirements every which way over the holiday, I'm certain that the minimum format we can get by with is

Anything less rich leaves us jumping through tremendous hoops, given the variety of data we have. Anything more rich ends up equivalent to XML, which brings on a huge dependency. Small opensource ini parsers exist for at least ruby, java, tcl, c++, c. I didn't hunt down bash and fortran. What I am not
yet convinced of is whether or not we'll actuallly need the nested sections extension which seems particular to one of the python config parsers; based on the relatively uncomplicated nature of the tutorial build, I intuit nested sections are not needed. -Ben

• We discussed on the telecon that the "data file" could be just the <proj-name>-config script. Is that now off the table? — Rob It seems to me that since we don't want this info in two different places, this is the logical place for it. — Rob
  • I'm fine with storing installation configuration values in project-config, but local project build and related information doesn't really belong there, imo (e.g., do any of the current tools use their own config file for their own builds?). The current tutorial is not representing any local project information at the moment outside of its makefiles. -Boyana
  • Boyana has an excellent point- build vs installed config should not be confused. The developer probably wants/needs to track both, but we want to generate an installed-config from the larger dataset used during source creation/build. Flattening the project data to an exported config format, or writing a config query utility, shouldn't be tricky.

• Create a resplicer callable from anywhere and capable of merging generated method code into Babel-generated impl files. A file-based resplicer is done (by Ben) and in his sandbox under 'dicer'. This makes it theoretically possible to generate a working component without ever editing babel-generated code.