<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 6/21/2011 11:35 AM, Jonathan Protzenko wrote:<br>
    <blockquote cite="mid:4E00E485.4090006@gmail.com" type="cite">
      <ul>
        <li>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.</li>
      </ul>
    </blockquote>
    <br>
    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.<br>
    <br>
    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).<br>
    <br>
    As I understand it, the high-level overview of what happens with
    composition is the following:<br>
    1. The codebase realizes it needs to open up an editor<br>
    2. The window is created (or reused, yuck) and fully initialized.<br>
    2.5 Initial message contents and parameters are set.<br>
    3. The user (un)happily edits their message via the UI--most code
    here is fairly contained within the editor<br>
    4. The editor's contents become serialized into the message envelope<br>
    5. The code sends the message envelope<br>
    <br>
    If we can agree on what the workflow should look like, I think the
    following plan of attack would work best:<br>
    1. Define where the boundaries between steps are and what
    information should be passed. Ideally this information should be
    minimal.<br>
    2. Modify the current code to add in the workflow boundaries<br>
    3. Modify the code to require only the information being passed
    through the boundaries<br>
    4. Start replacing broken code with clean, new working code, one
    stage at a time.<br>
    <br>
    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.<br>
    <br>
    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?<big><br>
    </big>
    <pre class="moz-signature" cols="72">-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth</pre>
  </body>
</html>