[Chandler-dev] Architecture Pilot Project Proposal

[Phillip J. Eby]

At 09:35 PM 10/15/2007 -0700, Heikki Toivonen wrote:
>Grant Baillie wrote:
> > Explicit non-goals:
> >
> > * Persistence layer: i.e. not saving user data (import from a format
> > like .ics is possible, especially for performance testing purposes).
> > * Sharing/email import.
> >
> > The lack of persistence is likely to be controversial in some quarters.
>
>You could say! :) Or maybe I did not understand the high level plan. Let
>me clarify: Is the plan to have testable, scriptable, extensible,
>high-performance Chandler UI that does not save anything anywhere
>(except RAM)? That is quite a bit different from what I thought the
>project was going to be.
>
>Still, I do see some value in that, and if you can really pull all that
>off in 2 months I am not worried one way or another.
>
>So assuming for a moment that I understood correctly, is the next step
>after that finding a backend that meets the performance etc.
>requirements of that non-persistent-Chandler?

Yes, along with porting the other features, the fleshing out of 
extension points for plugins, and the porting of plugins.

One important reason for doing it this way is what Andi pointed out 
the other day: currently, the application depends on the repository 
in unhealthy (for performance) ways.  So, we believe that the 
cleanest way to make the break is to go "cold turkey", and use any 
persistence system (including, most likely, the repository itself) as 
*purely* a persistence system for data, and nothing more.  That is, 
not as a UI specification, notification system, observer management, 
schema definition, etc.

The clean break also allows us to do some domain model refactoring 
and platform extensibility enhancements that would be extremely 
difficult to do in an incremental way.  And of course, we get to pass 
everything through a test-first filter to get 99.9% test coverage.