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

[Brian Kirsch]

On Sep 10, 2007, at 12:18 PM, Andi Vajda wrote:

>
> On Mon, 10 Sep 2007, Brian Kirsch wrote:
>
>> It would be a good idea to focus a discussion thread solely on  
>> Chandler 1.0 mail support. To me right now the biggest
>> barrier to Chandler being a full fledge IMAP client is performance  
>> and memory foot print. Isolating the mail object to
>> Item conversion and commit in a MailWorker thread for Preview  
>> really highlighted the performance deficiency.
>
> Really ?
> I thought that a decent mail rendering and composing UI was the  
> biggest barrier.
>

The reason I did not include this, and perhaps I should, was that I  
spoke of the need for a Rich Text  composition / HTML rendering
engine as a crucial part of our Chandler 1.0 strategy in a previous  
thread.


>> With a fast connection,The Chandler Mail Service can download and  
>> process 6,000+ messages before the
>> first 1,000 messages have been committed including notifications  
>> fired, observers called, and mail
>> indexed. That is a big discrepancy. There is a lot of redundancy  
>> in the notification and observer logic
>> which needs to be examined closely.
>
> True but how often does someone have to download 6000 messages ?
>

The first time they use Chandler as an IMAP Client :)

If it takes hours and not minutes (as it currently does) to download  
those 6,000 messages, I don't believe
users will find that satisfactory in the least.


> 1000 messages ?
>
> Isn't the day-to-day use of email, with a few new messages every  
> connect a more reasonable number to look at ? Is that also  
> currently too slow ?
>

This metric is much better than the large mailbox download scenario.  
If Chandler is downloading less than ten 1 meg emails then the  
noticeable
performance difference between say Thunderbird and Chandler is  
minimal assuming a fast internet connection and reliable performance  
from the
IMAP server.

As the number of messages to be downloaded increases, the performance  
metrics of Chandler decrease dramatically.
We can fine tune what is being downloaded ie. don't download large  
attachments but that does not
solve the primary issue of converting Python Message Object's to  
Chandler MailStamped Item's.
This is where the performance is really suffering at the moment.




-Brian



> Andi..
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev