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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
