Subject: Future Planning: Thunderbird as a Web App
To: Tb-planning
From: Kent James
Sent: Thursday, 17/09/2015 23:03:46 23:03 GMT ST +0100 [Week 37]
As we are discussing our future, both in relation to radical changes expected in the Mozilla platform, and our need to express where we are going to potential partners and donors, we need to discuss and agree on some big-picture issues. One of those was end-to-end encryption that we discussed recently. I want to discuss here our future platform, and how it related to users and their needs.
tl;dr Thunderbird over the next 3 years needs to convert to being a web app that can run on any browser that supports ES6 Javascript and HTML5. (web app does not imply cloud-based, only that the underlying platform is js/html).
There are two independent but both equally critical reasons why we need to go this direction.
First, the Mozilla platform itself has no long-term commitment to being available as a general-purpose development environment to run non-browser software, other than as a web app. At the same time, they are doing amazing innovations to allow more and more functionality traditionally associated with native clients to run under the "Web as a Platform" meaning the HTML5/ES6 stack. Really in the long run we will either have to fork the Mozilla platform and maintain it ourselves as an email development environment, or go with the flow and convert. Let's convert.
Second, more and more users are using a variety of platforms, including not only our traditional desktop environments but also Android and iOS (and other mobile OSes hoping to join them). I'm writing this message using Thunderbird on a Microsoft Surface 3 Tablet, which can now run traditional Windows applications such as Thunderbird. But we can't expect most of our users to buy a tablet from a second-tier operating system, merely to be able to run Thunderbird (as I did). In the last 24 hours, I have accessed my email using 4 different devices (Android phone and tablet, Windows desktop and tablet). Only 2 of those devices can run Thunderbird. We need to have a serious mobile story. Starting from the existing forward-thinking Mozilla web environment, we should be in an excellent position to convert our existing code to ES6-js/HTML5, and that is the best long-term way to support our users on the full range of platforms that they expect to use.
Last year, jcranmer introduced JsMime for some of the mime-related processing. This year, he is specing a Js database. I am working on JsAccount that will allow us to create new mailnews accounts and associated objects (server, folder, URL, protocol, etc.) using js and interoperate with our existing code. Although initially aimed at new account types, JsAccount will eventually make it straightforward to incrementally convert all of those core objects from C++ to Javascript. We need to plan to convert the entire backend in a similar nature to ES6 javascript.
Looking to a rough long-term schedule, I see future versions of Thunderbird looking like this:
38 (Avocet), 45 (3/2016 Bunting), 52 (01/2017 Cormorant?): Traditional XUL/C++ app
59 (09/2017 Dunlin?) Last and traditional XUL/C++ release. By this date, a reasonable possibility is that the Mozilla platform will no longer be usable for non-browser XUL-based development. This version of Thunderbird, in that case, would need to ship on a fork of Mozilla from the point where XUL-based development becomes untenable.
This will also be our last major XUL-based release, and we will not attempt to keep current with the new non-XUL Mozilla platform. It would also be useful to ship a stripped-down version of Thunderbird as a web app with this release.
07/2018 Egret? (no point in matching release numbers to Gecko anymore): Thunderbird ships a full-version web app.
I don't see what choice we reasonably have, given the announced changes in the Mozilla platform. We should view this as an opportunity to both get out from the current Mozilla regression-driven development, to being able to focus on our own issues. Hoping we can adapt to changes in the Mozilla platform, with no commitment from Mozilla that they will try to make that easy, is an enormous risk with little upside for us.
Comments?
On 9/17/2015 5:03 PM, Kent James wrote:
> As we are discussing our future, both in relation to radical changes
> expected in the Mozilla platform, and our need to express where we are
> going to potential partners and donors, we need to discuss and agree
> on some big-picture issues. One of those was end-to-end encryption
> that we discussed recently. I want to discuss here our future
> platform, and how it related to users and their needs.
>
> tl;dr Thunderbird over the next 3 years needs to convert to being a
> web app that can run on any browser that supports ES6 Javascript and
> HTML5. (web app does not imply cloud-based, only that the underlying
> platform is js/html).
There is one point of caution I want to make. The JS ecosystem is still
rather fragmented. An example of all of the different execution
environments:
* Node.js
* Mozilla XPCOM/Chrome JS
* B2G-style JS apps
* Chrome-style JS apps (/ web extensions?)
* JS apps in places like Windows RT (I don't follow mobile enough to
know all the fragmentation)
* Pure HTML5 webapps (including aspirational specifications)
Even basic APIs can be radically different between them--for example,
every single environment I've listed has a different API for reading
from a socket. There is a slow convergence between these different APIs,
but it's on the order of a few years. And, unfortunately, a part of the
missing API is rather fundamental concepts: node.js only started
embracing Promises with version 4, released this past month (!), and
Streams are still nowhere in sight.
There is also some good news in that JS tooling infrastructure is now
racing to properly support es6. I did grab code coverage of my latest
es6 codebase (an UTS #46 mapping tool, so I can feed that into JSMime),
and I'll probably poke at making it work with JSMime when I get time for
that.
I actually have more JS projects I've been working on:
1. JSMime (<https://github.com/mozilla-comm/jsmime>)
2. Emailsasl (a SASL client library)
(<https://github.com/jcranmer/TEMP-emailsasl>)
3. Email-socket (abstracting away the combination text control/binary
data nature of NNTP/SMTP/POP/IMAP) (not public yet, since I haven't
gotten very far with it).
4. UTS #46 support (<https://github.com/jcranmer/idna-uts46>)
Something that you'll notice is that I've been also making sure, at
least for the low level code, that I can work simultaneously with
node.js tests. I didn't do it for JSMime because node.js was in a really
horribly place several years ago, and I haven't had the time to go back
and do the fixes necessary to get it working.
>
> Looking to a rough long-term schedule, I see future versions of
> Thunderbird looking like this:
>
> 38 (Avocet), 45 (3/2016 Bunting), 52 (01/2017 Cormorant?): Traditional
> XUL/C++ app
>
> 59 (09/2017 Dunlin?) Last and traditional XUL/C++ release. By this
> date, a reasonable possibility is that the Mozilla platform will no
> longer be usable for non-browser XUL-based development. This version
> of Thunderbird, in that case, would need to ship on a fork of Mozilla
> from the point where XUL-based development becomes untenable. This
> will also be our last major XUL-based release, and we will not attempt
> to keep current with the new non-XUL Mozilla platform. It would also
> be useful to ship a stripped-down version of Thunderbird as a web app
> with this release.
>
> 07/2018 Egret? (no point in matching release numbers to Gecko
> anymore): Thunderbird ships a full-version web app.
>
> I don't see what choice we reasonably have, given the announced
> changes in the Mozilla platform. We should view this as an opportunity
> to both get out from the current Mozilla regression-driven
> development, to being able to focus on our own issues. Hoping we can
> adapt to changes in the Mozilla platform, with no commitment from
> Mozilla that they will try to make that easy, is an enormous risk with
> little upside for us.
>
> Comments?
I think it is absolutely vital to share maintenance work of "low-level"
protocol code with Gaia email or other components, by which I mean:
* IMAP, POP, SMTP, NNTP (not that Gaia is likely to do anything with
NNTP, but they all ought to share the same email-socket layer).
* MIME (+ TNEF decoding, S/MIME, PGP, I expect)
* vCard / CardDAV support
* iCal / CalDAV support
* Chat protocols
* JMAP
* Sieve / managesieve
I do want to counter that I'm not entirely sure the current state of
affairs is ready for us to go whole-hog on JS conversion. ES6 modules,
in particular, are a big change that is going to have lots of
repercussions, but no engines have fully implemented it yet (look for Q4
2015 or Q1 2016?), and some aspects of the standardization process are
in a holding pattern (e.g., HTML imports) until after people get more
experienced with them.
That's not to say we shouldn't move forward: rewriting some libraries in
JS (e.g., JSMime usage) is probably still worthwhile, and I think we can
get agreement now that new API design should be focused on ease of use
for JS consumers, with the XPIDL interface for C++ use being a
second-class citizen.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
The gaia mail back-end and any Thunderbird-evolved-to-webapp should
absolutely share protocol level code. (And as you've noted, gaia email
is already in the process of doing this in order to get streaming MIME
parsing via the JSMime library you authored for Thunderbird.)
It would also be great if we could reuse code at a higher abstraction
level too, but there's no clear evolutionary path for Thunderbird there
since the semantics don't line-up and it's hard to draw a clean line
through the Thunderbird implementation surface where things could be
easily shimmed/converted without throwing away large swathes of existing
Thunderbird functionality. (The refactored gaia mail backend, being
conversation-centric, is most akin to the gloda representation, but only
the faceted search UI and popular Thunderbird Conversations extension
consume that representation.)
My hope right now is that the gaia mail backend makes enough progress
that at some point in a few months I can make a pitch for people to
consider trying to help me create a desktop mail UI backed by the gaia
mail backend. I know, it's a very tall order for any app to provide the
feeling of immediacy that Thunderbird has; the thread-pane provides an
almost tactile experience. It's snappy after folder load, you know all
your messages are in there and with some combination of filtering,
sorting, and scrolling, you can usually find what you're looking for if
you look hard enough. (Compare with search-based mechanisms like Gmail
search or gloda global search where it can feel like sticking your hand
in a haystack and grabbing a bunch of stuff. Maybe the needle is in
that handful, maybe it's not. The sensation of being at a remove from
your messages can be frustrating.)
If anyone's interested in the current state, well, I'll send a different
message now with some pointers to tb-planning to avoid cluttering up
this thread.
Andrew
To put it another way: Thunderbird seems to spend a lot of time and energy keeping up with the changes in mozilla-central. What value does it get in exchange for that?
I'll grant that there's nothing that couldn't be replaced, but
there's quite a lot of core functionality there that you need in
an application before you can start building out what it does.
Mark.
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning
In the time since I started working on JSMime in 2011, I have had to
make exactly one change to JSMime to adapt for something Mozilla did,
and that wasn't even a core aspect of the code (it was my use of XHR
sync for use in non-TB test environments). There's a few things I'd like
to change (namely using typed arrays instead of binary strings, since
typed arrays didn't exist when I started), but not because I have to. In
contrast, there have been dozens of small changes and fixes that we need
to handle using the XPCOM infrastructure. Moving to a more pure JS/web
tech-based approach would actually reduce that level of minor change
adaptation, since there is far more conservatism about breaking
web-exposed APIs than add-on-exposed/internal APIs.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
We will have to convince Addon authors to convert away from XUL, so there needs to be documentation or workshops helping to get away from this. And obviously we need a transition time where "both" technologies can be used concurrently to find out about performance / compatibility issues. According to the timeline you give below, there is not much wiggle room there.
I'm using Android Gmail App to access my email in parallel with the more comfortable Thenderbird on my desktop when I actually try to get some work done. Most email providers already allow web access to their emails. But a unified Thunderbird frontend on Android and Firefox OS would sure be nice.
59 (09/2017 Dunlin?) Last and traditional XUL/C++ release. By this date, a reasonable possibility is that the Mozilla platform will no longer be usable for non-browser XUL-based development. This version of Thunderbird, in that case, would need to ship on a fork of Mozilla from the point where XUL-based development becomes untenable.can you elaborate what you mean? Forking would make XUL-based development impossible? Or XUL based development necessitates forking?
This will also be our last major XUL-based release, and we will not attempt to keep current with the new non-XUL Mozilla platform. It would also be useful to ship a stripped-down version of Thunderbird as a web app with this release.for the web app, will there be local storage? a "gloda-like" repository that can be stored on the hard drive? will the data be cross compatible with any other desktop email clients?
Any plans on who from the Thunderbird team could / would lead development. Are we going to get some help from the Firefox team?
I've done this research before, and the results aren't great. Our best
hope for LDAP is using OpenLDAP, possibly via js-ctypes. ldap.js is
based on node's networking libraries (see my last message about the
variability of networking APIs), and it is missing some features that I
think we would be loath to regress (e.g., SASL GSSAPI support).
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
Might there be a decent way to compile OpenLDAP into asm.js/WebAssembly
via EmScripten? That might be a way to get away from using actual native
code but still profit from that work - if it works decently.
KaiRo
I'm all in favor of addons as a way to manage complexity. It's great for me to hear that Hello wants to ship as an addon, as to me that means that Firefox will continue to think carefully of issues associated with using complex addons. But it is a good time to remind ourselves of that strategy. There are many pieces of Thunderbird that I would prefer to break out as shipped addons (such as junk mail processing, or LDAP, or account migration) only because they are major pieces of code only used by a minority that can complicate the UI and code for the majority.
Subject: Why we need Gecko updates (was: Future Planning: Thunderbird as a Web App)
To: Tb-planning, Gervase Markham
From: Ben Bucksch
Sent: Wednesday, 09/12/2015 00:40:09 00:40 GMT ST +0000 [Week 49]
No JavaScript stops 90% of the holes. But not all of them. Some are in
lower level libraries.
Ben
Mihovil Stanić wrote on 09.12.2015 09:04:
If remote servers are disabled by default and java script disabled in email, how big threat are those vurnabilities?
No JavaScript stops 90% of the holes. But not all of them. Some are in lower level libraries.
Subject: Re: Why we need Gecko updates
To: Tb-planning
From: R Kent James
Sent: Wednesday, 09/12/2015 21:14:32 21:14 GMT ST +0000 [Week 49]
On 12/9/2015 11:37 AM, Magnus Melin wrote:
I'd like to add to the above that forking m-c isn't likely as long as we could still build Thunderbird from it. If building gets impossible then you'd have to go from there.
Besides lacking security updates you'd also build on dead-end technology and nobody really wants to work with that a few years down the line.
I fully agree with this - up to a point. But the issue we face is this: MoCo is telling us that they do not want to spend any time on Thunderbird-related issues. If we take them at their word, then all of these requests we make to m-c for changes to support Thunderbird will no longer be accepted. In that case, m-c changes WILL break us. The option you are presenting is one that MoCo is telling us is not possible.
As I see it, you are asking that we assume that MoCo will continue with the status quo of the last few years, that is that they will give minimum attention to Thunderbird, but they will still keep us building. What I keep hearing them say is that they want to stop doing this, because the tax on Firefox is too great. Then there is elephant in the room, that they are really hoping to convert large parts of Firefox away from C++, XUL, and XPCOM and toward the servo-based browser using Rust. I cannot see any reasonable chance of converting Thunderbird to Rust, or even wanting to.
Looking forward, my crystal ball tells me this schedule:
Thunderbird 46 - 52 (TB 52 ships around 2017-01): Largely continue the status quo (though I think it is time to have our own branch of m-c, or of a merged m-c/c-c, so that we are not broken all of the time, and we can merge m-c to our build enviroment in a controlled manner including a few of our own fixes).
(Thunderbird 52 builds from mozilla-esr52, or the equivalent combined repo using merged m-c/c-c, from 2017-01 through 2017-12.)
Thunderbird 53 - 59: (TB 59 ships around 2017-09) Forked m-c, still using XUL and XPCOM, merging in security patches. No longer merging complete mozilla-central but only selected patches.
Thunderbird 59 builds using security patches merged in from mozilla-esr59, from 2017-09 - 2018-08)
Thunderbird 60+ Around 2018-08, mozilla-esr59 will EOL, and we will no long have any stable Mozilla repo to use as a basis for security patches. mozilla-esr66 will be too far from buildable with Thunderbird to be a usable base.
Here is the problem: to have any reasonable chance of switching to an alternate platform, the time required is probably 2-3 years. If we follow the current status quo, but otherwise keeping to the assumptions above, somewhere in mid 2017, the pain to try to continue using m-c will become too great,
but by then we will only have about one year left before any hope of keeping up with security patches is lost. If the project dies without security patches, then we are dead in 3 years.
At some point we are going to have to make assumptions about the future, and start acting on it. The current assumption is "Mozilla is bluffing". I can't buy that. You are welcome to challenge any of my assumptions, but just hoping that this issue is going to go away seems to me to be wishful thinking.
> Gervase Markham wrote on 18.09.2015 15:32: >> To put it another way: "what would we have lost if we had forked m-c two >> years ago"? Two examples beside security bugs: * Ongoing improvements to the JS engine and APIs: Within the past two years, this includes (off the top of my head) ES6, Promises, Tasks, OS.File, shutdown blockers. These have already been very useful, and are key for any attempt to move more of the backend code from C++ to JS.
Jim wrote on 09.12.2015 09:57:
it's probably possible to handle the remaining 10% on your own
Go ahead and try it.
I've tried.
I agree, and I neglected to follow-up, but this - 'surfing web pages
with TB' - is what I meant when I said the 'browser should be ripped out
at its roots'...
I understand that we need an HTML rendering engine for rendering HTML
emails, but that should be a very stripped down engine, no need for a
full blown browser engine. Personally, I don't see a problem with
completely disabling JS in the rendering of the email itself (separate
from magic done by Addons using JS)...
Subject: Re: Why we need Gecko updates
To: Tb-planning
From: Tanstaafl
Sent: Wednesday, 09/12/2015 15:12:12 15:12 GMT ST +0000 [Week 49]
On 12/9/2015 3:04 AM, Mihovil Stanić <mih...@miho.im> wrote: > If remote servers are disabled by default and java script disabled in > email, how big threat are those vurnabilities? > That doesn't sound like a big threat to me, but I might be mistaken. > > Additionaly, I really don't see point in surfing webpages with TB. I agree, and I neglected to follow-up, but this - 'surfing web pages with TB' - is what I meant when I said the 'browser should be ripped out at its roots'... I understand that we need an HTML rendering engine for rendering HTML emails, but that should be a very stripped down engine, no need for a full blown browser engine. Personally, I don't see a problem with completely disabling JS in the rendering of the email itself (separate from magic done by Addons using JS)...
Is there any noticeable work by FF devs to code stuff for TB?
They even called it "demands" from TB in the official message. Is there anything in m-c that was added just by TB requiring it? Is there code in m-c that they want to remove but can't because of TB? I am not aware of these cases, but maybe there are some. That is why I ask.
Or is it just that TB building/tests run on their servers? But then that does not affect the future direction of Firefox in any way.
______________________________________________________________
> Od: R Kent James <ke...@caspia.com>
> Komu: <tb-pl...@mozilla.org>
> Dátum: 09.12.2015 22:14
> Predmet: Re: Why we need Gecko updates
>
>On 12/9/2015 11:37 AM, Magnus Melin wrote:
>> I'd like to add to the above that forking m-c isn't likely as long as
>> we could still build Thunderbird from it. If building gets impossible
>> then you'd have to go from there.
>>
>> Besides lacking security updates you'd also build on dead-end
>> technology and nobody really wants to work with that a few years down
>> the line.
>>
>
>I fully agree with this - up to a point. But the issue we face is this:
>MoCo is telling us that they do not want to spend any time on
>Thunderbird-related issues. If we take them at their word, then all of
>these requests we make to m-c for changes to support Thunderbird will no
>longer be accepted. In that case, m-c changes WILL break us. The option
>you are presenting is one that MoCo is telling us is not possible.
>
>As I see it, you are asking that we assume that MoCo will continue with
>the status quo of the last few years, that is that they will give
>minimum attention to Thunderbird, but they will still keep us building.
>What I keep hearing them say is that they want to stop doing this,
>because the tax on Firefox is too great.
Specifically in response to "Is there code in m-c that they want to
remove but can't because of TB? " one good example is the cache
directory, which has been superseded by cache2 in FF but is kept for
Thunderbird. Another is the "deprecated" interface to the proxy code.
There have certainly been examples that I am aware of in character sets
as well, though they have been more aggressive there about removing
unneeded things.
There are also countless little ways throughout infrastructure in which
Thunderbird has code that is maintained, and places some burden on
Firefox. Think of AMO, BMO, Dataviz (that measures ADI), SUMO, Nucleas
(where release notes are written), and practically any other
infrastructure item, and there are little Thunderbird-specific features
that demand small amounts of attention from MoCo staff. Frequently
Thunderbird does not keep up with the current state of things, so the
versions that they maintain for us are older and therefore harder to
work with (think the old SVN website for example, where Kohei has
single-handedly brought us out of the old world into the new
Django/Bedrock world).
I also suggest that you listen to some of Chris Beard's speeches on Air
Mozilla about planning for 2016. One of the points he makes is that the
attempt of Mozilla to refocus on desktop Firefox requires that they
identify things that they used to do that are not adding value to
Firefox, and try to eliminate them. At the highest management levels,
they are looking around for what can be cut to allow better focus.
Thunderbird is an obvious target of this. (Apparently, so is Firefox OS
phones.)
I also do not think that we have the full story, and probably never
will. In my talks with Doug Turner about our infrastructure migration
(in which he was extremely cooperative and encouraging, by the way),
there were a couple of subtle hints about issues with Thunderbird. For
example, he thought we probably were not looking at crash stats (but
then I said we of course do, and our crash rate is lower than Firefox),
and he made comments about mostly unmaintained fundamental network code,
like for SMTP security. I don't think he is well informed here, and
probably has no need or desire to be well informed, but I took that as a
hint that Mozilla management may be concerned that Thunderbird is not
able to maintain the quality that they think should be associated with
the Mozilla brand.
Although there are lots of little points of intersection between
Thunderbird and Mozilla that could be the source of our tax, the area
they have asked us to focus on is release and build. I have not seen
anyone step forward and way, "Yes! I want to work on that". We really
need to find ways to solve this and move forward. Mozilla needs to see
that the Thunderbird team is willing to take on areas that cause high
levels of taxation in the Firefox world. How can we reorganize to do that?
:rkent
I also suggest that you listen to some of Chris Beard's speeches on Air Mozilla about planning for 2016. One of the points he makes is that the attempt of Mozilla to refocus on desktop Firefox requires that they identify things that they used to do that are not adding value to Firefox, and try to eliminate them. At the highest management levels, they are looking around for what can be cut to allow better focus. Thunderbird is an obvious target of this. (Apparently, so is Firefox OS phones.)
I have talked to asuth a fair amount over the past few years about the
interaction of Gaia email and Thunderbird; unfortunately the relevant
IRC channels aren't logged, so I can't point you at those records.
The basic summary, though, that we can both agree on is that there is
very little that Thunderbird had to offer Gaia email when it was started
up. The state of JS libraries was extremely poor back then (and is still
somewhat shoddy), so trying to contribute shared JS code from Gaia to
Thunderbird is difficult, particularly because Thunderbird is extremely
feature rich, and I don't think any part of the relevant JS libraries is
at feature-parity with our code yet (!). For example, SMTP, the simplest
of the core protocols, needs to support GSSAPI, CRAM-MD5, NTLM SASL
auth, non-UTF-8 8-bit-messages (thanks, Japan), proxies, and message
delivery notifications, none of which Gaia's library (emailjs.org's
smtpclient) supports.
Having talked with both the Gaia email and the emailjs.org people, I've
more or less gotten people to agree on some of the changes to be made,
but I've lacked any time to actually develop those changes. If people
can spare some time, fleshing out the email-socket library and hooking
up smtpclient and email-sasl to that would open the doors to being able
to share some more code between various email projects.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
Back when I was originally exploring adding new account types in 2007
(!), the two account types I was looking at implementing were mailing
list archives and web forums. It's worth pointing out that Mailman 3 has
talked about (implemented? I'm not entirely sure) exposing their archive
history via NNTP, since it's sort of the exact kind of simple protocol
that's useful for indicating archive histories.
> In the immediate term, I think our area of overlap continues to be JS
> implementations of protocols.
Would it be possible to draft you or someone else on the Gaia email team
for structuring JS library imports into comm-central? As we look into
moving stuff into JS, it would be great to share the protocol
implementations more widely, and that really means that we need to make
it easier to port between smaller package repositories (like JSMime) and
comm-central. Thunderbird has a sufficiently large userbase that it's
arguably the best chance for email-relevant libraries to actually make
sure they work on real world data by confirming that they can be used by
TB's multi-million-large userbase.
For what it's worth, the rough list of stuff that is sanely shareable
IMHO: POP, IMAP, SMTP, NNTP, chat protocols (IRC, Oscar, Yahoo, MSN,
???), LDIF, vCard, CardDAV, iCal, CalDAV, MIME (+ mbox, S/MIME, PGP,
TNEF, uuencode, yEnc), SASL, Bayesian message classification,
SIEVE/MANAGESIEVE. Probably a few utility libraries as well.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
Indeed. I seem to recall talking to someone who said cache2 should not
be difficult to implement.
I should think that Seamonkey would also want this.
Great to hear Doug is so engaged. And yes both crash-stats (mostly major
crashes only) and bugzilla reports are well looked after - although I
think it's mainly just me and Magnus (and standard8 prior to that), so
we need others would step forward to share the load [1].
And yes our crash rate is far lower than Firefox's, about 1/3 [2].
Although I suspect our users data is a little more at risk from
corruption and loss from crashes.
[1] crash bugs filed in past year: http://mzl.la/1J0suhi
[2] crash rates ...
Graph: http://imgur.com/iQ5MDn1
TB query: http://bit.ly/1O0m6hD
FF query: http://bit.ly/1NgxAtO
> and he made comments about mostly unmaintained fundamental network code,
> like for SMTP security. I don't think he is well informed here, and
> probably has no need or desire to be well informed, but I took that as a
> hint that Mozilla management may be concerned that Thunderbird is not
> able to maintain the quality that they think should be associated with
> the Mozilla brand.
Given the fact that there is no active module owner, sure, there is
reason for concern. But then, over the last 10 or so years, we've rarely
had security issues in these areas.
Can you clarify... Do you mean making sure protocol libraries are
available as npm-packaged modules? Making comm-central be able to use
npm-packaged modules? Other?
Andrew
I'm imagining that we want each protocol to be available as a separate
npm package, and my thought is that they would leave in separate
repositories that are kept more-or-less in-sync with comm-central. How I
packaged JSMime was intended to follow that model, but since it's built
into a single file for comm-central, it makes moving changes between the
two versions painful. It's possible that my thought is a distinctly
worse development proposal, though.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
If we picture a world where we both receive upstream code regularly
which we incorporate into our product, as well as maintain modules that
we hope others will share from us, I think it would be better if we flip
the model of where the canonical repository is. That is, we should keep
things like jsmime as separately downloadable packages on github, and
then have code in client.py (or something similar) that pulls specific
version of upstream repositories into our code tree. We still need some
mechanism to allow us to land Thunderbird-specific changes locally, if
only for urgent changes, perhaps using a CANONICAL_UPSTREAM branch for
updates, then merge into our default branch.
If someone wants to use jsmime (or other shared packages) outside of
Thunderbird, they need some convenient way of specifying the changes
that they need without having to understand all of the complexities of
interacting with the Mozilla world, and any required changes in
Thunderbird to support that. Github is the most common way this is done
these days, and you see much Mozilla code migrating there already. Yes
it makes our life like a little more difficult, but I think it would be
great if we would learn to be more cooperative with other groups, and
making jsmime and similar packages follow typical open source comment
and pull-request patterns would help with that.
Plus if we ever start using packages like react in our own code, we are
going to be forced to support this approach anyway.
:rkent