<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Joshua Cranmer 🐧 wrote on 19.04.2017
04:30:<br>
</div>
<blockquote type="cite"
cite="mid:aaf6823e-319c-79ba-e2fc-3b7acefb7b9f@gmail.com">
<meta http-equiv="Context-Type" content="text/html; charset=utf-8">
<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">
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>
</blockquote>
<br>
Yes, I see the same in other contexts, e.g. the UI, that there are
not enough powerful APIs in JS. A lot is done with arrays. Using a
slightly higher level API (e.g. collections, or streams/buffers)
consistently across all the components would dramatically help. At
least JS strings are Unicode :).<br>
<br>
I think emailjs.org libs are a good starting point. I've merely
started with emailjs, because of asutherland's endorsement, he
worked with them a lot, and I respect him highly, so that was a good
start. However, it's very likely that at some point, probably rather
early, we'll find the libraries lacking and will adapt or rewrite
them. Or we might find better existing ones.<br>
<br>
That's not a problem, though. As long as we have good abstract
high-level APIs, we can swap out the underlying implementation
without problem. It the APIs are too particular, it's very hard, as
you found with JSMime in current Thunderbird and Kent found with
JsAccount.<br>
<br>
Just case in point: As you might have seen in a few of my posts, I'm
currently working on a little prototype for the Thunderbird
successor. Nothing works yet, so I haven't shared it. I had started
with my |Account| API and the IMAP and POP3 implementations that I
had written in JavaScript a few years ago, and that were used in a
commercial project, but are under MPL. I naturally started with
them.<br>
<br>
Then, last night, as a test, I rewrote the entire IMAP
implementation, now using the emailjs.org IMAP library, to try that
one out. And I was positively surprised. The API is straight-forward
and works exactly as I expected. The overall design was very similar
to what I had designed independently of them. I had the emailjs IMAP
based implementation working within a few hours. It was easy to work
with and worked straight away (modulo being unclear with SSL vs.
STARTTLS, but many have that confusion). And, best of all, I didn't
have to change my API even one bit. I could swap out the entire IMAP
implementation and the rest of my code didn't need to change. This
is because the API was sufficiently high-level and I had avoided
leaking particularities of the implementation into the API. That's
something that's impossible with current Thunderbird.<br>
<br>
So, a) the emailjs libs are a starting point, for the MVP approach,
and b) we're not stuck with it and can change implementations later
as need arises. And most importantly it shows c) the importance of a
good, clean API.<br>
<br>
A lot hangs off good code design, framework and APIs: Fast progress,
new contributors, maintainability, easily fixing bugs, adding
features, up to extensions.<br>
<br>
What you're saying about about consistent Buffer APIs across
components goes into the same direction.<br>
<br>
Ben<br>
</body>
</html>