<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hello TB-Planning members (and especially Ben/Jim),<br>
    <br>
    This email is to address those who have been stressing that we
    should not even consider the option of forking Gecko if/when we get
    to the 'fork or die' stage, but should just immediately focus
    efforts on a total rewrite of Thunderbird from scratch.<br>
    <br>
    First, please understand that I actually love the idea - but only
    with some caveats.<br>
    <br>
    First, to resources. As everyone here knows, TB dev resources are
    very limited right now.<br>
    <br>
    My understanding is that most-if-not-all of the existing resources
    are currently focused on just keeping up with the changes Firefox is
    pushing, as well as some smallish but very welcome bug and feature
    fixes. So, the main question has to be, just how much of existing
    resources could be re-focused on a total rewrite (whether it was
    Glodastrophe or something else)?  Obviously, resources working on
    feature fixes are an option, but this is really a question only Kent
    or a few others can address, and I would really like to hear from
    them on this. The key point being, if it isn't enough to even
    remotely come close to getting the job done in the time-frame. For
    the one biggest problem about that particular question - meaning,
    what exactly is our time-frame - see my prior email about the
    removal of XUL/XBL(/XPCOM).<br>
    <br>
    If it is taking all (or even most) of the current resources just to
    keep up, then refocusing those resources on a total rewrite is not
    really a viable option either, unless new resources are found. That
    said, I readily admit that this is a real possibility (especially
    after Kents welcome news about the status of donations coming in!),
    as there may be a lot of devs out there who would be more inclined
    to work on something shiny and new, rather than slowly
    fixing/rewriting parts of something old and crufty.<br>
    <br>
    That is a big question mark at this point, so I'll leave that on the
    table.<br>
    <br>
    However, I also have an even more important point to make.<br>
    <br>
    In order for a total rewrite to be a valid option, then it must by
    definition include a formal and very strict goal of actually
    duplicating TB's current UI/feature set to a great extent,
    especially including the ability to customize the UI and feature set
    just like you currently can, both with Addons, and probably as well
    as directly through config file(s) (like you currently can with
    user.js, userChrome.css and userContent.css).<br>
    <br>
    The bottom line is, anything else simply doesn't qualify as a
    'rewrite of Thunderbird', it is just the writing a new email client
    from scratch. Of course, this is not a bad thing in and of itself,
    but Thunderbird lovers want a shiny new Thunderbird, not just
    another new mail client, and if TB resources are to be used for such
    a project, UI/customizability/feature-set parity with current TB is
    an absolute must.<br>
    <br>
    If the project goes down this road, I can envision a large job for
    those like me who are not programmers, but love TB nonetheless, of
    going through the current bugzilla for TB, and compiling a (probably
    long) list of bugs/enhancements that should be worked into the
    rewrite goals, and creating new ones too.<br>
    <br>
    Personally, I would also argue for a modular approach for key
    functionality - the three big ones I can think of off the top of my
    head being the Composer, the HTML rendering engine, and mail storage
    engines. These could be implemented as what Kent referred to as
    'FirstClass Addons'. For the Composer, there are a number of open
    source HTML editors out there that claim to be 'drop-in' capable, so
    this one should definitely be doable. We could just pick the best
    one, implement it as a FirstClass Addon, and if anyone prefers
    another one - just implement it using the existing Addon as an
    example/starting point. You're on Windows and prefer to use the
    Microsoft Edge (or Opera) rendering engine? Develop an Addon to
    enable it (it would obviously require the desired engine to be
    installed and available). You're on a Mac and prefer the Safari
    rendering engine? Same thing. Now, the rendering engine would likely
    be a lot harder than the editor to get right - maybe even impossible
    for some engines due to lack of API/hooks - but I know that Outlook
    used to use the IE rendering engine (I recall the huge outcry (still
    ongoing) when MS switched it to use the Word rendering engine), so
    it apparently can be done, the only question is if it is feasible. 
    For the mail storage formats, start with Addons for maildir and mbox
    formats, then someone could add support for dovecots m/sdbox formats
    too if they wanted.<br>
    <br>
    Oh - I would also strongly recommend reaching out to the main IMAP
    server developers/projects (dovecot, cyrus, fastmail, others(?)) for
    ideas and input an the design of the core/inner workings (not the
    UI). Timo (dovecot author and primary dev) has expressed an interest
    in writing a new email client (I think he mentioned it would
    primarily be IMAP based), and I think his input would be extremely
    valuable.<br>
    <br>
    Something else I just thought of. I seem to recall a long, long time
    ago, I believe it was in Netscape 4, there was an ability to store
    your settings in LDAP. I'd also love a way to do something similar,
    maybe not in LDAP. Imagine, you get a new computer, install the
    shiny new TB, and the first time it opens, there is an option to
    'Import Settings'. This could be from a local file, or how about a
    WebDAV server? Dropbox? FTP server?) - you enter the required
    info/credentials - and presto, TB restores all of your settings -
    Accounts, Passwords, Addons and their configs, etc.<br>
    <br>
    Man, I'm drooling now.<br>
    <br>
    Ok, enough of my meanderings, time to go get some work done.<br>
  </body>
</html>