Why a fresh start (was: Proposal to start a new implementation of Thunderbird based on web technologies)
ben.bucksch at beonex.com
Fri Mar 24 20:45:35 UTC 2017
R Kent James wrote on 24.03.2017 19:41:
> I know how hard it is to trace through the muck of existing
> implementations to try to figure things like, how do I get the UI to
> actually show the change I just did without having to do a restart or
> resync? And now Ehsan says things like "oh by the way, we're not going
> to allow protocol handler newURI in the future written in JS" and now
> the whole scheme collapses, and JsAccount is going to have to adapt.
Right. How much of your time have you spent a) writing the JS code that
keeps the list of accounts, and the object representing an account, and
the associated functions and b) trying to get all this hooked up to all
the rest of Thunderbird? Can you give a very rough estimate of hours for
I can tell you that with a fresh new implementation, it would take me
less than 1 day for part a), and part b) wouldn't exist, because the UI
is written anew using HTML anyway and would use the new API straight
away. Even if my numbers are a bit off: You see why I think that a
gradual approach is at least 4 times slower than a fresh start?
And that's not even considering the fact that a fresh start can use
design patterns correctly, which Thunderbird currently doesn't.
We're not talking about a small refactoring here, but replacing all the
core technologies and languages. Essentially, converting gradually is
like converting a 1969 Corvette into a 2015 Corvette, by replacing one
part after another. It just doesn't make sense.
> But at the same time, many, many attempts at rewrites fail.
I've personally managed 2 rewrites of commercial projects, and in both
cases, we finished faster than estimated, had no major problems on
release (much less than Version 1), and went from 1 million users to 3-5
million users, within a year. Of course, that was paired with a
marketing effort, but Version 1 also got marketing.
> The most valuable asset that Thunderbird has is our userbase, which in
> spite of lousy communications and "Thunderbird is Dead", continues to
> slowly grow. ADI on March 6 was 10,258,971 which I believe is a new
> high, though we have been at just over 10,000,000 now for a couple of
> years so growth is very slow. It is absolutely critical that we bring
> our users along with us
Kent, I totally, 100% agree on that. I dedicated a whole section of my
proposal to that.
> I have serious doubts about whether a sudden change to a new UI and
> program is something they would follow.
Agreed. That's why I don't want to do that, but preserve the UI. That's
explicitly the goal, for that very reason, because I completely agree
But we don't have much choice in the matter, right? XUL (or at least
parts of it) is going to go away sooner or later, no matter what we
> I also am aware that one of the most challenging platforms is likely
> to be 1) embedded in existing Thunderbird as an addon. I know the
> existing nsIAB* interfaces pretty well, and interfacing with them at a
> low level (as nsIAbDirectory implementations) is extremely
> challenging. Practically it is impossible, as any reasonable future
> API for Thunderbird contacts would be async, while the existing API is
> fully sync with a hidden async implementation used in LDAP and relying
> on UI notifications. So bolting onto Thunderbird is only going to be
> possible by rewriting existing Thunderbird to support an async
> Contacts interface.
Right! This is the kind of thing I mean, why a gradual rewrite would
take so much longer than a complete rewrite. Because you can also use
> You (Ben) are saying that rewriting Thunderbird to support a new
> Address Book implementation is not worth the effort, instead we should
> hold back, and wait some years before we make this available to our users.
2 years for most users, to be precise.
How many years are we already talking about overhauling the address
book? 3-5 years, if my memory serves me. Indeed, my memory still serves
me: It was none less than Mike Conley, in May 2012, 5 years ago:
Where are we today? Nothing happened. Yes, you're right, there were more
attempts, afterwards, all failed. I still have that old thing here. Why?
Because it's so hard to rewrite with the given constraints of
Thunderbird. So, years later, we're nowhere. The task itself isn't that
hard, I'd guess 3 person months for a talented, experienced developer.
We need to get moving, and a fresh start will allow us to drive fast,
and get somewhere.
BTW: If some volunteer wants to then backport the new AB implementation
to old Thunderbird, that would be great. But he's in for something...
I hope this post here clarifies why I think that a fresh start is our
best option at this time.
More information about the tb-planning