Hi everyone,
I'd like to share my perspective on this issue a bit. I've come at
Chandler from the side, and I don't claim any deep knowledge of any
specific part of the architecture except maybe MultiStateButton :-).
wx is pretty straightforward for anyone who has written desktop
applications. Events get handled, UI widgets get constructed, life is
pretty much as it should be. There are the usual difficulties that
are part and parcel with supporting multiple OS's, themes, etc (c.f.
toolbars).
The repository, although a bit overwhelming at first, is not only
well documented in "application/schema_api.txt", but behaves as one
would expect a data store to behave. It, too has bugs, but Andi is
pretty much on top of things.
When I try to trace UI creation, I hit something of a wall. Where I
would expect code to go into an __init() and proceed normally, there
is a large wall of abstraction with "template" methods and schema
attributes for what should be simple member variables. Although I can
appreciate what this high-level abstraction does, and why it is
there, this has to be weighed against the burden put upon developers
who have to go through this learning curve. I still don't think I've
finished it myself.
I don't think the complexity of instantiation is worth the modicum of
increased functionality it affords. (Oooh, I almost said "affordance").
Reid
On Sep 12, 2007, at 18:53, D John Anderson wrote:
I can relate to this argument. However, from my vantage point I see
it a little differently.
For the parts of the code I understand well (or better yet, the
code I wrote) I'm very comfortable working on it. Sure, I wouldn't
have done CPIA if had known the goals it was designed to solve
would eventually be dropped, and yes, I'm all for improving it.
For the code I didn't write or don't understand very well, e.g. the
repository, I find it frustrating to work on. And even though the
repository API is documented, I still find it difficult to work on.
I'm sure if I were in Andi's shoes I'd feel exactly the opposite.
The same goes for wxWidgets, which is documented and has lots of
people working on it.
Sometimes when we've changed the architecture in the past -- for
example changing the way we do stamping -- I've found the new code
more difficult to work on and understand than the old code. I
suspect the reason might have more to do with my lack of
understanding than an advantage/disadvantage of a particular
architecture.
Having worked on so many different software projects over the
years, some of which I designed from the ground up and others that
I started working on late in their life, I can relate to Grant's
frustration trying master a pre-existing large code base. All of
the successful projects I've ever worked on eventually fall prey to
complexity . Sometimes that kills them. Sometimes the attempted
rewrite to improve complexity kills them. More often than not, the
ones that live the longest do the best job at balancing re-
architecture with new features.
So, I'm probably most comfortable with a middle ground. Doing a
some re-architecture while focusing on improvements that make
customers happy. I also think that we could also benefit by using
some of our time working on tests suites to test various
components, e.g. test the repository, in isolation of the rest of
Chandler.
John
On Sep 12, 2007, at 2:14 PM, Grant Baillie wrote:
Hi, Jeffrey
I meant to reply to your email early, sorry.
Personally, I've been considerably frustrated by how hard it is to
write code on our project. I don't work so much at the CPIA layer,
but below that the "brittle" and largely undocumented API problem
really impacts my productivity, whether it's because it makes
making changes more difficult, or whether it's because I'm often
having to be distracted to revisit old changes that have turned
out to have had surprising and negative consequences.
I can elucidate exactly which brittleness I find difficult, but
this is the high-level picture. I feel strongly enough about all
this that I'm quite sure I would be pretty unhappy chipping away
at the code base the same way that I have for the past 12 months.
--Grant
On 6 Sep, 2007, at 17:28, Jeffrey Harris wrote:
Second guessing past decisions is unlikely to be fruitful, I'm
not interested in recriminations, but I'm not sure we're all on
the same page about whether the existing architecture is
problematic. Is there frustration? How bad is that
frustration? Where is it focused?
So, personally, the CPIA layer, which I think is persisting lots
of things that seem to me to be UI details, is frustrating to
work with. I'm also worried about the notification/observer
universe, but (perhaps because I understand it better) I'm not
particularly frustrated with this (except when I'm trying to
improve performance).
If I could, I'd back up to 2005 and model recurring events as one
item, not many. The current model is frustrating to work with,
but I'm not sure how feasible it would be to change this now, so
I'm not thinking we'll change recurrence any time soon.
I've been wondering if it would work to have a few developers
work on replacing CPIA, without making radical changes to
collections/notifications (for now). In this scenario I envisage
most developers focusing on incremental bug fixes and small
features that new users clamor for.
Sincerely,
Jeffrey
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
