[Dev] 4th tenet for 0.7: modular APIs

[Katie Capps Parlante]

As we've been deep in 0.7 planning (1), three tenets have been coming 
together that frame the release: plausible dashboard, plausible 
scheduling, and further support for an experimentally usable calendar.

When we look at the work that the platform team is planning for the 
release (2), much of the work supports those tenets. We'd like have a 
fourth tenet that frames the rest of the work, and helps give us focus 
during the release. When brainstorming about this at the end of the year 
(3), the platform team talked about focusing on the platform APIs.

Phillip Eby framed it this way:

- A developer should be able to learn and use Chandler APIs in a modular 
fashion, referring only to a component's dependencies and not the 
components that depend upon it.

- A "component" can be defined as compact, conceptually cohesive units 
that are able to be separately developed, distributed, and used.

The proposal is to focus on modular api's in 0.7. Reasoning:
* Modularization and API work would firm up our foundations and allow us 
to expand the scope of extension parcels in 0.8.
* It is the first step in talking about stable APIs, which are going to 
become more important if we are to attract parcel developers.
* It will help us develop better unit and functional tests.

Presumably this focus would mean not expanding the ui scope of extension 
parcels much beyond the flickr-like parcels we support in 0.6. Ok, I 
suspect that cleaning up the APIs would in fact greatly expand what a 
parcel developer could do, but that would not be the explicit goal.

I'd also note that its not just the platform team who'd be doing work 
that supported this tenet -- cpia work would also fit in here.

Thoughts?

(1) http://wiki.osafoundation.org/bin/view/Projects/ZeroPointSevenPlanning
(2) http://wiki.osafoundation.org/bin/view/Journal/PlatformMtg20060124
(3) http://wiki.osafoundation.org/bin/view/Journal/DevMtg20051213

Cheers,
Katie