[Chandler-dev] What is next for Chandler desktop?

[Grant Baillie]

There have been a lot of postings on this thread (yay), some of which  
I'll still be replying to. I'm picking Mimi's because it's somewhat  
high level. At a high-level, there are two questions I see here:

A) What to do when
==================

1) Don't rearchitect anything: just fix bugs, incrementally add  
features, except for the ones that are impossible (I'm thinking  
mainly scaling to real-world email volume), until the end of 2008.

2) Attempt to develop in parallel: i.e. have some fraction of the  
team work on adding relatively low-impact and desirable features,  
like scripting, printing and month view, so that there are  
appreciable signs of progress for end users.

3) Bite the bullet and rearchitect (whatever that means -- see below)  
now, taking the position that this way we'll be better placed to Give  
Users What They Want.

B) What does "rearchitecture" mean?
===================================

This is the question (or presentation of options) raised by PJE early  
on in the thread:

> 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

I should point out that it is a good idea to bear in mind approaches  
that have been known to work elsewhere (i.e. things like Model-View- 
Presenter or Model-View-Controller).

In addition, keeping performance and scalability in mind. I have had  
in the past heard a description of the existing architecture (by a  
Chandler developer) start out with "Assume an infinitely fast and  
scalable repository ...", which needless to say puts somewhat hard-to- 
satisfy requirements on the repository :o.

Anyway, my point is mainly to separate out the two issues. I'll  
clarify (hopefully) a little more about B1-3 in some subsequent emails.

--Grant

On 6 Sep, 2007, at 17:00, Mimi Yin wrote:

> I wonder if this is too stark a way to frame the situation.
>
> I think we all want Chandler-the-code to be easy to maintain.
> *And* we all want to have users for Chandler-the-product so that  
> Chandler-the-code will be worth maintaining.
>
> (I think the concern people have is that without a real user-base,  
> no one will bother to maintain / add onto Chandler, even if it's  
> the easiest code to work with in the world.)
>
> The question in my mind is more: How should we balance  
> rearchitecture with user-driven improvements to Chandler-the-product?
>
> I'm about to post a response to this thread on the design list  
> which hopefully addresses this very issue. Looking at the bug list,  
> deferred feature list and user feedback, I'm not sure we need to  
> decide between users (features) and code (rearchitecture). I'm  
> hoping we can be responsive to users with a 'FIX WHAT'S BROKEN'  
> approach and defer major feature work until after 1.0. Anyway, I  
> will leave you to read the design list email for a more coherent  
> framing.
>
> Mimi
>
>
> On Sep 6, 2007, at 4:20 PM, Phillip J. Eby wrote:
>
>> That having been said, I don't have as much invested in Chandler  
>> as I did in either of those projects.  The first I was a minority  
>> shareholder in the company, and for the second I was creator/ 
>> auteur and project manager.  On Chandler I'm just "hired help", so  
>> it's not my money and it's not my vision.  But I'd *still* like to  
>> see it around 5 years from now, and from that perspective I don't  
>> see the end-of-'08 functional requirements being nearly as  
>> important as non-functional requirements like performance and  
>> maintainability.
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev