Hi Folks, On Tuesday Grant and I had a lengthy conversation on IRC about rearchitecture. You can see the whole conversation at [1], or read what follow for a brief summary.
Executive Summary ----------------- We've got a reasonable catalog of the features we want to plan on tracking for our first pass at the interaction model, see [2]. We aren't sure whether we should do domain model work first, or if the two can be usefully separated. The next steps are to choose an order of attack for what tests to write, make SWAGs of how long they'll take, and divvy up the work. Making rearch outside-dev friendly ---------------------------------- We're going to try to have good test coverage of our interaction model. We'll try to write more documentation with embedded doctests, so our documentation doesn't get out of date. As we try to make rearch more modular and pluggable, we plan on making extensive use of entry points for features. Since these entry points will be one of the major points new developers interact with Chandler, we think it's important to have documentation of the entry points we define and use. Ideally, we'd have high level, doctested documentation for major entry points, and also an automated index of all entry points declared and associated documentation. We'd like to talk more with PJE about how best to do this. We're going to standardize our code style a bit more on PEP 8 [3]. Testing ------- - strive to have a doctested README.txt for each package, marked up using ReStructured Text - standardize on putting tests at the root level, named test_* - add a test_suite.py which will typically run test_* and doctest *.txt PJE's time ---------- PJE's time is limited, projects we'd like him to work on: - birefs in the Trellis, so the coherence of facts like "item A is in collection X" and "collection X is one of item A's collections" are maintained automatically by the Trellis with reasonable performance - persistence - work on generic presentation layer in wx We agreed that it'd be nice but isn't essential to have PJE's assistance with the latter two, but birefs are pretty important. Other stuff we'd like to chat more with PJE about ------------------------------------------------- - is text displayed in table view part of interaction model (IM)? yes - what about geometry dependent text? perhaps tags on the IM component - in making rearch more pluggable, how would a plugin disable and replace a "stock" feature? - how should plugins that provide user visible features (menus, detail view bits) describe in what order they'd like to be placed? Is it enough to have plugins provide a weight? [1] http://chandlerproject.org/script/getIrcTranscript.cgi?messagesOnly=true&channel=chandler-rearch&date=20080923 [2] http://chandlerproject.org/Developers/InteractionModel [3] http://www.python.org/dev/peps/pep-0008/ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
