Re: Summary of the situation with the composition process — thoughts wanted
Pidgeot18 at verizon.net
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
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...
More information about the tb-planning