[Chandler-dev] What is next for Chandler desktop?

[Phillip J. Eby]

At 02:58 PM 9/6/2007 -0700, Bryan Stearns wrote:
>Phillip,
>
>I'm all for the idea of improving testability of Chandler - I just 
>don't have a picture in my head of what form that would take, nor do 
>I understand what process you're suggesting we use to get there.

A good reference is the old "Spike" design:

http://svn.osafoundation.org/chandler/trunk/internal/Spike/src/spike/overview.txt

Specifically, the "Five Layers" section is a good overview of what we 
see as an organization for testability.

(The rest of the document isn't necessarily up to date, though, since 
we're no longer using parcel.xml, and it doesn't discuss EIM at 
all.  But it's not bad as a background on some possible ways to deal 
with the other issues covered there.)

As for the process, the basic development process would center on the 
interaction model and domain model layers, with stubbed storage and 
detached UI.  That is, we would develop Chandler application features 
without a GUI, and without a repository (or any other form of 
persistence!), using test-first code as behavioral specification on 
both the unit and functional testing levels.  GUI development and 
storage development (including such issues as how things should be 
indexed) would proceed in a decoupled manner.

This would allow us to experiment with different data storage 
mechanisms to select the best approaches for performance -- even to 
mix and match them for different aspects of the application, to 
maximize overall performance.

Currently, performance-related risks are significant, and we have 
very little ability to decouple storage mechanisms from the main 
application.  The repository has some back-end pluggability, but if I 
understand correctly, this occurs at too low of a level for us to do 
application-specific tuning.

Right now, application-specific tuning is done through code that's 
propagated through the application code, in the form of creating and 
managing specialized indexes.  These concerns shouldn't be part of 
the interaction or domain layers, but segregated to code that can be 
independently tuned.

In the current situation, the cost to make a change to these 
optimizations is high, as is the probability that feature changes 
will de-optimize a previously-optimal configuration.