Re: Summary of the situation with the composition process — thoughts wanted

Joshua Cranmer Pidgeot18 at
Tue Jun 21 20:18:19 UTC 2011

On 6/21/2011 11:35 AM, Jonathan Protzenko wrote:
>     * The Herculean undertaking that this represents. There are
>       zillions of options and of possible behaviors; more than a sane
>       man would get crazy trying to implement them all. I even
>       regularly discover some new options myself: the thing with
>       multiple identities for one single account, all preferences
>       regarding composition (top-posting vs bottom-posting, signatures
>       above/below the quote, signature / no signature, quote / no
>       quote, font, color, html, plaintext, html + plaintext, utf8, no
>       utf8), s/mime, attachment reminder, MDN, DSN, autosave,
>       different composition modes (edit draft, reply, reply all, new,
>       etc. I think there are 14 of them), initial attachments, were we
>       called through mapi, command-line, drag&drop of attachments
>       from: the filesystem, another email, an URL... I believe some of
>       these options should go away, even if some users are going to
>       crucify us for this. I don't think we have the manpower to
>       undertake a rewrite of the composition process and still afford
>       to keep that variety of customizations.

I'll admit that I don't recall much of the nsMsgCompose workflow off the 
top of my head, but here are some of my thoughts.

Rewriting compose in one batch would be pure insanity. Applying lessons 
from my current rewriting work with DXR, if you decide that you want to 
fix the entire flow of the code, it is far, far better to take each step 
in process. While it's admirable that you've done so much work, it would 
probably be better to slice this up into smaller steps and rewrite each 
step individually over the course of weeks, months, even years (sadly).

As I understand it, the high-level overview of what happens with 
composition is the following:
1. The codebase realizes it needs to open up an editor
2. The window is created (or reused, yuck) and fully initialized.
2.5 Initial message contents and parameters are set.
3. The user (un)happily edits their message via the UI--most code here 
is fairly contained within the editor
4. The editor's contents become serialized into the message envelope
5. The code sends the message envelope

If we can agree on what the workflow should look like, I think the 
following plan of attack would work best:
1. Define where the boundaries between steps are and what information 
should be passed. Ideally this information should be minimal.
2. Modify the current code to add in the workflow boundaries
3. Modify the code to require only the information being passed through 
the boundaries
4. Start replacing broken code with clean, new working code, one stage 
at a time.

Of the features of which you say that we have too many, most of them 
basically boil down to either saying "I want the initial message to look 
like this" or "I want to set this parameter before sending"... if we can 
cleanly separate workflow stages, it should be possible to get by 
without sacrificing any of those.

But, at the very least, I think we need a sense of what we want the 
compose code to look like in Thunderbird ∞, so we can produce a roadmap 
and start implementing it. It sounds like this is what you're 
volunteering to help do?

Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list