Hacker News Reader

Hacker News

Comment by EntiPag | Hacker News Reader

Parent Full thread

EntiPag

> Email messages are ASCII only. You can put non-ASCII characters into a header however. It looks like this:

To me that is a good example of how email is flexible, and also simple.

It's flexible because it could support non-ascii text strings, without changing a thing.

It's simple because the protocol doesn't care what the subject says. It only cares that it's an ASCII string.

That sounds like good engineering to me, as well.

You could argue that a new version of the email protocol could be improved to do away with those hacks, but that doesn't take anything away from email's simplicity and flexibility.

View on HN

Email is simple the way a plane is simple. As long as you don't see all the moving parts, and get to go along for the ride, it just seems like a magical flying tube!

I spent about 18 months on an email client project (was already 3 years in when I joined the team). I can tell you email is insane... so much more broken than you would expect (on all sides).

There is a reason many clients do "gmail" instead of "email". "Email" is a nasty barely functional ball of duct tape greased with WD-40 in the places it needs to go fast -- the fact that it works at all is breathtaking and only explained by the fact that it is one of the "killer features" of the internet.

The number of broken clients and servers is shocking and breathtaking. So you have to accept and expect bad data from everywhere. From the server directly, violating the imap spec, and in the body of the message violating all sanity. Yet, your users will see any failure as "this email client sucks" because the OTHER older email clients have already seen this idiocy and custom coded around it. Email clients end up being giant laundry lists of "if <stupid server> (act way 1)", "if created with <stupid client> (render 'right' way 2)"...

The reason new email clients are relatively slow to be created, and even fewer take off, is they are forced to deal with an insane clusterfuck of standards and corner cases to get to that 80% good enough mark -- or simply build out to one service at a time (we support gmail, hotmail and yahoo... etc).

There are 20+ RFCs you need to deal with the cover the spectrum of "basic" email with calendaring across a number of servers. That is just the "good" standard parts. On top of that you have the hundreds of server oddities that you need to handle else your email client will fail to get email off broken server X. Add to that the hundreds of rendering special cases you need to be aware of (ohh, this game from old outlook, so X means Y).

After you do all that, you have to deal with spam (both how servers tell you about it, how you show it, how you maintain it, etc) and an entire new set of oddities (very similar but simpler) for sending mail.

FastMail has an idea floating around that appears less terrible: http://jmap.io/ -- but I am blissfully out of that industry and simply don't care anymore.

EDIT: For the record, I agree with the article, email will be around for a long time, it is the "point of record" -- many of the "email killers" require your email address to sign up... so...

That's why we built Inbox. :)

https://www.inboxapp.com/

In short, the Inbox API is a translation layer between IMAP's eccentricities and modern JSON REST endpoints. Plus it's open source free software.

Wow, how long have you guys existed? I am shocked I didn't know about this product. That is IMHO, EXACTLY the product that has needed to be built for awhile. Get all those eccentricities into one library that provides a clean interface.

We announced this a couple of months ago, though the company has been around for a while. We're also just quieter than most startups. Less blogging and talk, more code. :)

Looks interesting. IMAP is a pain! We spent months trying to get really simple stuff working for a mail client we're building (http://www.sortd.com). Actually, to be accurate it runs inside Gmail because it's more of a way to manage email rather than a standalone client, but we still need to connect to the mailbox itself via IMAP. Started using context.io, which was useful, but they went kind of wayward from their original vision.

What about performance though? Things like search are almost just not viable with IMAP - WAY too slow - we find ourselves having to hack the Gmail DOM to do things we should be able to do directly via the mailbox.

Seems to me that IMAP needs to be updated or replaced. What do you think of the new Gmail API?

> To me that is a good example of how email is flexible, and also simple.

I fail to see how a complex encoding is "simple". (Maybe I should mention that there are complex rules about where that encoding can appear, and there's two variants of it)

> It's flexible because it could support non-ascii text strings, without changing a thing.

No, clients had to be upgraded to support it.

> It's simple because the protocol doesn't care what the subject says. It only cares that it's an ASCII string.

Well, sure; why would the protocol care about it? But at some point you're encoding the email for delivery (say, you're a web service) or you're an email client trying to display it. At that point, its a deceptively simple not-ASCII string.

> but that doesn't take anything away from email's simplicity

I'm arguing that you have a twisted definition of "simple".

Reply on news.ycombinator.com