[Chandler-dev] [Sum] The Great Architecture Discussion of 2007
aparna at osafoundation.org
Mon Oct 8 19:16:20 PDT 2007
I never had a chance to fully pipe into this discussion esp from the
QA point of view.
During the on-site week, I finally had the opportunity to speak with
a few of
you about Chandler testability. This was particularly for me to
understand why this was such a difficult problem to solve. After
understanding the layering of the components (or the lack of) in our
came to understand a lot of the issues already being discussed on the
I believe the consensus across board was that the way we were
structured currently, with our monolithic architecture, we couldn't
achieve much testability without some sort of
restructuring or refactoring. Now, this is specifically for vast
majority of tests we want to add to
test the application logic without going thru the UI . John's
will help us with tackle the UI level tests.
Some ideas that followed from the discussions were:
1. While we are doing shorter release cycles, not all developers may
have bugs to fix in each release. Those who have the time
afforfance could start some simplified refactoring work of their own
components in the branches.
2. A few developers can work on the refactoring project, for e.g. say
replacing CPIA, while most other devs focus on the incremental bug
fixes and small features that users are asking for
Though it is easy to swing in extremes, from doing nothing at all to
doing a mass Chandler rearchitecturing project, I would like to hear if
there is any middle ground that can be achieved.
Apart from the larger goals of sustainable code base etc, this is
important for making shorter release cycles successful without the
unattainable effort of
manually going thru 13 test specs and some 1200+ testcases for each
On Oct 8, 2007, at 8:24 AM, Grant Baillie wrote:
> 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
>> 3. Develop an architecture specifically to suit Chandler's current
> 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
> 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.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "chandler-dev" mailing list
More information about the chandler-dev