My personal agenda for TB 52
Joshua Cranmer 🐧
pidgeot18 at gmail.com
Fri Jan 22 20:53:17 UTC 2016
On 1/22/2016 9:23 AM, ace wrote:
> 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
<https://github.com/jcranmer/jsmime/tree/mime-emit>), 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
of CRAM-MD5, SCRAM-SHA-1, SCRAM-SHA-256, PLAIN, LOGIN, XOAUTH2, and
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.
Thunderbird and DXR developer
Source code archæologist
More information about the tb-planning