back

by rcarmo·11y ago·view on hn ↗
I, for one, am somewhat leery of people reinventing the wheel - especially for a browser-based environment, where everything has a history of being brittle and short-lived.

IMAP works amazingly well if you're using dovecot as a server (including search and push e-mail), and CalDAV/CardDAV also work well if your server actually implements things properly, and projects like Horde have shown you can run and deploy web-based services for them at scale (even though I still regret they're using PHP).

Sure, anything related to DAV has more than a few warts, but my main point here is that things like JMAP won't cater to an installed base or deliver benefits across the board until they finish filing all the corners on their shiny new... cube? Dodecahedron?

1 comments
> I, for one, am somewhat leery of people reinventing the wheel - especially for a browser-based environment, where everything has a history of being brittle and short-lived.

Yeah, so are we (and we even introduce JMAP with the "now you have X standards" XKCD comic). This is our last resort. We've been pushing the limits of what's possible with IMAP for years, and we've come to the conclusion that there's just some things you cannot do efficiently with it.

JMAP is not not just for browsers, though that has been where our focus is so far. I have partial implementations of JMAP for fetchmail and mutt already done (I'm just trying to find time to finish them and get them out there). Yes, JMAP uses JSON for its data encoding and (currently) HTTP for its transport, but it's not inherently browser-based.

> IMAP works amazingly well if you're using dovecot as a server (including search and push e-mail), and CalDAV/CardDAV also work well if your server actually implements things properly, and projects like Horde have shown you can run and deploy web-based services for them at scale (even though I still regret they're using PHP).

The problem is, if you're not using a server like Dovecot or Cyrus that does implement all the extensions to IMAP that you need to get a modern email experience, then you're screwed. Ditto if your client doesn't support it. So we end up in the situation where we have all this stuff that is technically IMAP-compliant (ie implements RFC 3501) but gives a half-assed experience to the user.

Worse, if you wake up one morning and decide you want to build some amazing new experience on top of standards-compliant email, you'll spend the next few months trying to get your mail client bits working correctly before probably giving up. Even if you do get it working, you'll still have to work out what to do against servers that don't support CONDSTORE and QRESYNC. This is why all these pretty new mail-based apps generally target Gmail exclusively - it's a known environment.

So that's what JMAP is about. Use it and you get a straightforward protocol based on tech you probably already know that supports things you expect in 2015, like push, assistance on flaky networks, battery friendly, etc.

> Sure, anything related to DAV has more than a few warts, but my main point here is that things like JMAP won't cater to an installed base or deliver benefits across the board until they finish filing all the corners.

Do you see anything missing from the spec?

We recognise that this doesn't work without everyone supporting it, which is part of why we're releasing the spec and all this code and talking to every company with an email product that will listen. This won't work unless everyone can play and its easy for them to do so. We don't want to own this; that doesn't help anyone.

I don't know if JMAP will win. Something has to change though, that I'm convinced of. The web had its revolution (a couple of times). We think its email's turn.

When I read the spec the push support was ungood.

What it should do: Tell the server an XMPP or HTTP endpoint to which the server should push a specificed opaque blob when new mail arrives, and possibly other opaque blobs corresponding to other changes, and a (non-binding) rate limit.

With that, it would be easy to write a low-overhead server to support a particular mobile client. Accepts opaque blobs, decodes a little, sends blob to phone via giantmobilevendor.com (which also uses XMPP/HTTP), needs to store no state.

That's pretty much exactly what it does. Client supplies a HTTP endpoint, that gets called with new state strings. That endpoint arranges for that information to be shipped to the client and then the client issues calls to update methods to get its view of the world up to date.

Its easy to extend to a custom (non-URL) method type if you like, and works well with mobile push channels. This is what we do with our mobile apps at FastMail to push through GCM, APNS, ADM and Pushy.

Glad to hear you've fixed that, then.