Joining forces vs. starting from scratch (was Re: Proposal to start a new implementation...)
ben.bucksch at beonex.com
Wed Apr 19 03:32:07 UTC 2017
Joshua Cranmer 🐧 wrote on 19.04.2017 04:30:
> On 4/10/2017 9:47 PM, Ben Bucksch wrote:
>> o Implementations of MIME, IMAP, SMTP
>> o Definitely need to look at this, potentially use it.
> 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.
> 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
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 :).
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.
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.
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
project, but are under MPL. I naturally started with them.
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
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
A lot hangs off good code design, framework and APIs: Fast progress, new
contributors, maintainability, easily fixing bugs, adding features, up
What you're saying about about consistent Buffer APIs across components
goes into the same direction.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning