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