<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 4/10/2017 9:47 PM, Ben Bucksch
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c86dcda4-bd9a-f7fe-6ae7-0f5fdc5e17c1@beonex.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
emailjs.org
<ul>
<ul>
<li>Implementations of MIME, IMAP, SMTP</li>
<li>Definitely need to look at this, potentially use it.</li>
</ul>
</ul>
</blockquote>
<br>
I did a writeup of the email.js SMTP implementation in comparison to
Thunderbird's current implementation two years ago (wow, has it
really been that long). The general conclusion is that it bakes in a
lot of assumptions that aren't really safe for general use (for
example, email messages are only ASCII body contents, or ignoring
SMTP features not found on gmail like delivery status notification).
The response from the email.js people was more or less "feel free to
go ahead and rewrite large portions of it to suit your needs", but
there is a fair amount of rewriting that has to be done there to
make it more amenable to some of the tasks to support.<br>
<br>
One of the issues that comes up when doing these sorts of libraries
is platform support. It turns out that the standard JS library is so
sucky you need a lot of little things to do useful stuff, and
there's a few components that end up getting needed to be shared
between all of the libraries. Doing the
dump-this-ASCII-in-an-ArrayBuffer or base64 conversion ends up
cropping up in a lot of places, yet the pieces are so easy that it's
generally not worth the bother to create an entire library with an
entire dependency for just one thing. Whatever we do, I strongly
encourage some base utility libraries just to avoid the fifteen-fold
duplication of this stuff that will crop up otherwise.<br>
<pre class="moz-signature" cols="72">--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist</pre>
</body>
</html>