<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 4/3/2017 5:00 PM, Ben Bucksch wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:04657f83-217c-630d-3c16-f40726ad23ce@beonex.com">Joshua
      Cranmer ­čÉž wrote on 03.04.2017 18:08:
      <br>
      <blockquote type="cite">
        <br>
        We've talked about rewriting Thunderbird for, oh, a decade or
        more now. We've had agreement on the direction these rewrites
        should take for at least 3 or 4 years (rkent was really one of
        the last hold-outs for using JS). But we've not really made any
        measurable progress on rewriting Thunderbird.
        <br>
      </blockquote>
      <br>
      And you know why? Because nobody started. If we had started "a
      decade or more" ago, we would be done since 5 years, would not be
      fighting Gecko regressions today, and would be adding the features
      that the users today are screaming for.
      <br>
    </blockquote>
    <br>
    It is a lie to say that no one started. There have been at least two
    projects with the clear intention of rewriting major portions of
    Thunderbird that produced concrete results yet have failed to come
    to fruition (Ensemble and JSMime), and depending on how and what you
    want to count, probably another 4 or 5 that didn't produce
    actionable results or were not clearly intended to replace existing
    code (e.g., Raindrop, Gloda). If you want to make progress, you need
    to learn from mistakes. Denying the existence of those mistakes will
    only lead you on the path to ruin.<br>
    <blockquote type="cite"
      cite="mid:04657f83-217c-630d-3c16-f40726ad23ce@beonex.com">
      Inaction is our biggest risk. The task is big, but doable. It's
      been done before.
      <br>
    </blockquote>
    <br>
    Inaction is not the biggest risk. I am not proposing inaction. I am
    not objecting to the idea of rewriting most/all of Thunderbird.
    Hell, <i>I have put more work into rewriting Thunderbird in the
      past decade than you or probably anyone else on this thread has</i>.
    That's not the problem with your proposal. The problem is that
    you're suggesting... well, basically inaction (on a feature level)
    while you go off and work on a separate project, hopefully to force
    it down everyone's throats when it's done. And arguing that it will
    be so wonderful and timely that there's not going to be any problems
    forcing people to switch (I am aware that this is probably a gross
    caricature of what you're proposing). <b>That</b> is what concerns
    me: that you're going to hit a roadbump, and everything is going to
    go wrong, and there is going to be no Plan B.<br>
    <br>
    The biggest risk is that one snag derails the entire project.
    Suppose, for example, that you have problems with unacceptable
    performance on message display, and that this resists all attempts
    to bring it to the performance level of existing Thunderbird code
    for years. (This is not unrealistic: this is exactly what happened
    to ical.js). What do you do? This is the sort of risk that concerns
    me deeply, and the best way to mitigate is to minimize the
    criticality of delivering any one individual feature. Proposing a
    complete rewrite and not seeking gradual uplifiting is exactly the
    opposite of that strategy.<br>
    <br>
    I will reiterate, again, to take a look at how Mozilla is
    integrating Servo into Gecko. Note what they are doing (moving
    things piecemeal) and what they are not doing (halting development
    of Gecko while they implement Servo). This is a project with far
    more available resources, both absolutely and in proportion to its
    size and userbase, than Thunderbird.<br>
    <br>
    <blockquote type="cite"
      cite="mid:04657f83-217c-630d-3c16-f40726ad23ce@beonex.com">
      We do have a fallback. Thunderbird based on Gecko would continue
      to be supported on the current level.
      <br>
    </blockquote>
    <br>
    That is not a backup plan, especially not if XUL Gecko dying is one
    of the main motivations for embarking on this project.<br>
    <br>
    <blockquote type="cite"
      cite="mid:04657f83-217c-630d-3c16-f40726ad23ce@beonex.com">
      The 2 projects would run in parallel and independent of each
      other, they share the project umbrella and the goal. The teams
      would be separate. The Thunderbird-based-on-Gecko team would be
      free to pick any JS/HTML implementations created for the new
      client and backport them to the old client. I'm pretty sure we'd
      finally get the new AB this way.<br>
    </blockquote>
    <br>
    If you expect the end-goal to be "TB users get
    force^H^H^H^H^Hauto-upgraded to new product" and expect that to go
    without serious objection, you are sorely mistaken. There needs to
    be communication and liasons between the two teams if you want it to
    go smoothly. Some more points:<br>
    <br>
    1. Realistically, you're proposing a skeleton maintenance team for
    TB, more or less what we've had for the past 5 years or so. This
    team will likely have to spend so much of its time keeping TB
    building that they are unlikely to have much time or ability to port
    new components to it.<br>
    2. Thunderbird has 15+M users, your new product will have maybe
    hundreds. Email is rife with buggy implementations and has no
    general conformance testsuite, so you're not going to find problems
    until you get actual users with their weird edge cases. Your
    developers should be jumping at the chance to have their work in
    Thunderbird.<br>
    3. I am not proposing to maintain the current APIs. Nor am I
    proposing to maintain the current feature set. What I am proposing
    is that the idea of "how can we get this into Thunderbird without
    getting all the unfinished stuff" should be a first-level concern.
    The answer might be that it's impossible--transitioning the database
    API is perhaps infeasible, and as a result, migrating anything that
    relies on the database wouldn't be possible. On the other hand,
    structuring your nntpclient implementation to roughly correspond to
    the methods on nsINntpService does seem like a good idea.<br>
    4. There is a lot of great technical knowledge stored in the TB
    repository (in a hard-to-read form, sure). It's easy to make
    assumptions based on specifications that aren't true in practice
    (e.g., the charset of message headers), and it's all to easy to make
    a design that's hostile to the changes needed to support those
    assumptions (this, broadly, is the failure of libmime).<br>
    <br>
    <blockquote type="cite"
      cite="mid:04657f83-217c-630d-3c16-f40726ad23ce@beonex.com">
      The gradual rewrite is what has failed. That's not just a
      possibility. We tried and failed. As you said above, we wanted to
      do it since a long time, and never succeeded. Thinking that we'll
      suddenly succeed now, with less resources, is merely wishful
      thinking. And if that fails, Thunderbird is dead for good, because
      XUL is going away eventually.
      <br>
    </blockquote>
    <br>
    The glaring failures we have are not that the rewrites failed. We
    could have had CardDAV 5 years ago, but we decided to have it
    implemented in Ensemble instead. I could have finished EAI support
    years ago, instead I made it contingent on JSMime. Those rewrites
    failed ultimately due to lack of manpower, and not because they were
    trying to maintain current APIs (Ensemble didn't try to, JSMime did
    seek to maintain compatibility in the interim but wasn't designed on
    it).<br>
    <br>
    I keep going back to Servo, but it's a good model IMO. By all means,
    incubate implementations in a product outside of Thunderbird. Feel
    free to experiment on alternative methodologies without worrying
    about how exactly to squeeze it into Thunderbird. <b>BUT</b> when
    you draw up the roadmaps, when you write out the work plans, when
    you farm out the coding tasks, have bullet points that ask "What can
    we deliver to Thunderbird?" Servo is not the replacement for
    Firefox, it is the product in which improvements to Firefox are
    incubated.<br>
    <pre class="moz-signature" cols="72">-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code arch├Žologist</pre>
  </body>
</html>