[Chandler-dev] Framing discussion about desktop architecture

[Reid Ellis]

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