Why a fresh start
vseerror at lehigh.edu
Fri Mar 24 21:36:38 UTC 2017
On 3/24/2017 4:45 PM, Ben Bucksch wrote:
> 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
> each part?
> 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
> with you.
> 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
> decide here.
>> 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
> modern APIs.
>> 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
> 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.
Actually, "talking" about it since 2007 :) where it was a known
impediment and under consideration, but it didn't make the first and
second cut for Mozillamessaging to take on the work. 2012 was just the
first time any action was taken, much less a spec.
It was my understanding that architectural constraints were never an
issue (or at least not a major issue) - the only issue was manpower.
Part of the plan (perhaps not on the wiki) was to write a new AB backend
abstracted such that it would easily transfer to a new platform. These
were things were discussed.
More information about the tb-planning