[Chandler-dev] [Sum] The Great Architecture Discussion of 2007

Grant Baillie grant at osafoundation.org
Mon Oct 8 08:24:49 PDT 2007

Since there have been around 80-odd messages on chandler-dev@ on the  
subjects of architecture, testability, and What Do We Do Next, it  
seemed like a plan to try to summarize the story so far. I've kind of  
grouped things under several themes; hopefully this will be.

In the summary below, the *Agreement* parts indicate, roughly, 2-3 or  
more people concurring without any significant disagreement. If you  
feel your dissent has been ignored, or you didn't register it, feel  
free to say so.

There are also a couple of topics I'm explicitly not covering, since  
they have already become (recent) history:

* 0.7.1 feature set and timing
* frequent releases

Overall direction and requirements for the project
Katie's original email stated the next goal as being "to build a user  
base and a working community".

*Open Issues*: At the time was what, specifically, this means. E.g.  
how do we prioritize courting users vs developers, or short-term bug  
fixes and feature work vs longer-term rearchitecture. More generally,  
the issue of making the project sustainable (i.e. finding revenue  
opportunities, or building a developer community to maintain Chandler  
in the long-term) came up.

Prioritization issues are covered by Katie's recent email:


Also, for PPD's take on what they would like addressed, see Mimi's  
design list posting:


Rearchitecture vs End-User Feature Development

There was some concern (e.g. from Brian K, John, Andi) that a major  
rearchitecture/rewrite will time away from developing end-user  
features, and fixing bugs that impact end-users (i.e. being  
responsive to our users). This would in turn hinder adoption, which  
could have disastrous consequences for the project.

*Agreement*: Having everyone "drop tools" to work on rearchitecture  
(i.e. longer-term goals) would not be good.
*Agreement*: There was some support (Jeffrey, Morgen, PJE, Heikki,  
John) for having a smaller group attack architecture on the side,  
possibly starting out with CPIA. PJE pointed out that this could be  
done similarly to previous work of his at OSAF (schema API and EIM),  
where a couple of developers were involved initially, before others  
moved over to the new architecture as needed.
*Agreement*: (PJE, Paul) Focusing only on getting end-users will not  
be enough to make the project sustainable once funding expires.

PJE: Testability is a requirement for the goals laid out in Katie's  
original email, and is therefore a "wedge issue" for the whole  
discussion. Testability is also necessary to build a developer  
Morgen: Testability has been vital for development and ongoing  
maintenance and feature development of syncing code.
Heikki: Testability has not been a requirement in the development of  
a well-known family of open source web browers whose process he  
happens to be familiar with.
There was some discussion of testability in the thread following  
Aparna's "Desktop Test Automation Project" email. In the standard  
layered approach, we could tackle testability of presentation layer  
code with a mock wx.

Architecture and goals
PJE's desirable architecture: (i.e. separated layers, for testability  
and pluggability) is the old spike project he did a couple of years  
back. (Some of these ideas have since been incorporated into Chandler):


PJE's 3 architecture process options, quoted:

> 1. Start with the current architecture and evolve it in-place
> 2. Define a new architecture in terms of "off-the-shelf" Python  
> components
> 3. Develop an architecture specifically to suit Chandler's current  
> goals

The first minimizes upfront costs (rearchitecture) vs less apparent  
later costs (time to stabilize releases).

Andi, John, Heikki: Favour incremental vs more radical architecture  

CPIA/Persistence in the UI

Katie's original email suggested that we shouldn't be persisting so  
much of the UI structure of the app. John noted that transparent  
persistence was a refreshing contrast to other systems he'd worked  
on, where you had to write SQL queries every time you needed to  
persist something. Philippe pointed out that having everything be  
persistent is confusing for new developers: it's hard to make sense  
of all the attributes that get tied to even simple items when  
displayed in the UI.

PJE: What we need is to separate out visual presentation (not  
persistent) from application logic (e.g. which items are selected in  
which collections, etc). That leads to greater testability (you can  
test the application logic without the UI). Ideally, you could  
separate out persistence as well, which means you can run tests of  
the application without the repository. Greater separation means more  
opportunity for parallel development (i.e. of views vs interaction  
model vs persistence) of features.

*Agreement* (Philippe, PJE, Reid, Andi, John, Mikeal): Cleaner  
separation of UI from the rest of the app.
*Agreement*: (Philippe, PJE, Andi): Not persisting redundant/constant  
UI data.
*Agreement* (John, PJE): The current template mechanism in Blocks is  
confusing and mostly a historical artifact, so it should be removed.

Performance, Scalability

*Open Issue*: (Grant, Andi, Brian K) Unclear what the goals are  
w.r.t. email beyond what we have today. Need measurements of how  
Chandler performs in the presence of many items (and/or collections),  
as well as explicit performance goals.

Timing of 1.0 Release

Davor: Shouldn't a "1.0" release happen pretty soon (a few months)  
after a "0.7"?
Piero: Not necessarily (depends on what needs to be addressed).  
Project needs some kind of a roadmap.

More information about the chandler-dev mailing list