My personal agenda for TB 52

Joshua Cranmer 🐧 pidgeot18 at
Fri Jan 22 20:53:17 UTC 2016

On 1/22/2016 9:23 AM, ace wrote:
> Hi.
> Yes, it could be interesting if we had a wikipage or some list of what
> larger projects people are working on in the longer term.
Well, email can make a surprisingly effective wiki.

As for my current projects and their statuses:

* Bug 1211292 - Rewriting nsMsgSend (I don't count the .cpp file on 
purpose; the backend infrastructure is splayed out among a dozen files 
or so). This is really a big project, so let's break this in pieces:
** The low-level support for converting a MIME tree to an RFC 822 blob 
is basically complete (see 
<>), but there's 
basically no tests and insufficient documentation. Part of my reason for 
sending out the last message I did on JS-ification was to plumb some 
waters as to normalizing the review and development process of JSMime.
** The code to build top-level headers (InitCompositionFields and 
mime_generate_headers in the C++ code) is almost complete and thoroughly 
tested thanks to test_messageHeaders.js
** The code to build the MIME tree 
(HackAttachments/GatherMimeAttachments + lots of subcalls) is about 40% 
done. I have no support for the ingestion via editor (and consequently 
multipart/related support), and there's lots of holes with respect to 
features like charsets or format-flowed or attaching messages.
** Support for S/MIME is not even attempted yet.
** Support for the actual sending steps (via 
SMTP/NNTP/save-to-folder/save-to-file) is not attempted yet, although 
I've sketched out some ideas for how this would work, including 
supporting JSAccount custom-send functionality.
** I've not tested any sorts of error conditions or abnormal code paths; 
in particular, the integration with send reports is quite poor.

Unfortunately, the main blocker here is that so much of the compose 
tests are essentially broken in their logic, and so I end up spending as 
much time fixing tests as I do fixing bugs in my own code (this is why 
I've started paying more attention to the utility of tests as a 
reviewer--I don't want tests that have to essentially be changed 
everytime you change the code). The other problem is that, as I detailed 
in the bug, the code is incredibly featureful and previous attempts to 
break the problem down into smaller refactorings ended up taking just as 
long (e.g., it took 9 patches in my queue to make nsMsgSendPart into a 
separate interface I could rewrite in JS).

* emailsasl (no bug) - I was motivated to write a SASL client in JS 
after seeing the failure of emailjs's smtpclient to support CRAM-MD5 and 
other SASL mechanisms. So far, I actually have a working implementation 
ANONYMOUS, and I'm currently working on NTLM, leaving only GSSAPI and 
EXTERNAL as the last two mechanisms to support. It's not really in a 
form that's easy to replace our current SASL code, however, and I still 
want to test it in a real protocol afterwards to see if its API is 
working or not.

* nntpclient, or, using JSAccount to replace our current NNTP backend 
with a JS one. I chose NNTP because it's arguably the simplest, or at 
least most self-contained, and I understand it better than any of the 
other ones. It's the proving ground for my email-socket work, although 
fully testing it is hampered by the fact that I waffled on how to 
represent an asynchronous iterator API. I suspect I'll wait until 
Streams is implemented before trying to test poking it into the tree.

* Test coverage improvement bugs. These are very low priority for me, 
and I'd be more than happy to yield them to someone else if someone 
wants to work on them. Basically, I have prototypes for testing MAPI 
code, SSL, and S/MIME code, as well as some promisification passes 
through complex tests that I return to every once in a while to get more 
scenarios tested. I'd also like to see some tests against real servers 
rather than fakeservers (most important for LDAP, for which writing a 
fakeserver is not an enticing proposition); I have some dockerized 
containers for OpenLDAP and Dovecot, but I've not made any headway on 
getting tests written against our code to use them. Performance tests is 
a nice-to-have, but I was thinking of saving that for a GSOC project.

* Build system cleanup, including m-c/c-c merge. The merge itself is 
dependent on release engineering working out the automation steps for 
the merged tree, which tends to be a slow process.

Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

More information about the tb-planning mailing list