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:
http://tinyurl.com/2eph43
Also, for PPD's take on what they would like addressed, see Mimi's
design list posting:
http://tinyurl.com/ypq5hn
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.
Testability
-----------
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
community.
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):
http://svn.osafoundation.org/chandler/trunk/internal/Spike/src/spike/
overview.txt
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
changes.
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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
