5 ms·

I'm really not sure what I feel about the naming. It's one letter off (both on the keyboard and alphabetically) from IMAP. Is this an attempt to coattail the wi

I'm really not sure what I feel about the naming. It's one letter off (both on the keyboard and alphabetically) from IMAP. Is this an attempt to coattail the widespread recognition of IMAP or just an extremely unfortunate name collision?

rhabarba 7y ago
There is a use case example for replacing IMAP: https://jmap.io/#representation-of-email https://jmap.io/#representation-of-email
diroussel 7y ago
The original authors of JMAP were IMAP experts who were increasingly frustrated with IMAP. So not it’s not a coincidence. It just started as IMAP over JSON and then ask they fixed issues and added features it became its own thing.
lloeki 7y ago
{a,b{,a},k,z,{,t}c,fi}sh come to mind and it's fine. The name makes perfect sense, given it's an alternative to IMAP built on JSON messages.
chrismorgan 7y ago
It has been jested in the Fastmail office that one of the requirements for a spec to be adopted by the IETF is that it have a clever name. Have a look around the mail and calendar specs, for example; there are many amusing names. JMAP is a generic protocol, but its primary motivating example and the thing that has influenced the design most is email, as a replacement for SMTP (between the user and server, not between servers) and IMAP. The name JMAP was chosen quite early on. I + 1 = J. The words the acronym stands for have changed a couple of times along the way!
jcranmer 7y ago
JMAP is pretty explicitly meant to replace IMAP. IMAP was originally conceived essentially to allow a very thin client that proxies every user command back to the user store, and it also embeds some reliance on old implementation artifacts (UIDVALIDITY, anyone?). There are a lot of "fun" corner cases--I once found a message that was interpreted 5 different ways by 4 different implementations. (It doesn't help that MIME structure is actually pretty loopy and maps very poorly to how all modern clients view mail messages, resulting in many interesting interpretations). Modern email clients are all structured very differently from the "thin client" perspective--everyone keeps their own copy of the email (metadata) database locally, and use IMAP essentially as a database synchronization protocol, but IMAP is pretty bad at synchronization, at least until the LEMONADE additions came in ~a decade ago. IMAP is especially bad at handling multiple folders correctly, since it assumes that every folder is independent of the other ones, and you can only sit and wait for messages on one folder per connection at a time.

rhabarba 7y ago

There is a use case example for replacing IMAP: https://jmap.io/#representation-of-email https://jmap.io/#representation-of-email

diroussel 7y ago

The original authors of JMAP were IMAP experts who were increasingly frustrated with IMAP. So not it’s not a coincidence. It just started as IMAP over JSON and then ask they fixed issues and added features it became its own thing.

lloeki 7y ago

{a,b{,a},k,z,{,t}c,fi}sh come to mind and it's fine. The name makes perfect sense, given it's an alternative to IMAP built on JSON messages.

chrismorgan 7y ago

It has been jested in the Fastmail office that one of the requirements for a spec to be adopted by the IETF is that it have a clever name. Have a look around the mail and calendar specs, for example; there are many amusing names. JMAP is a generic protocol, but its primary motivating example and the thing that has influenced the design most is email, as a replacement for SMTP (between the user and server, not between servers) and IMAP. The name JMAP was chosen quite early on. I + 1 = J. The words the acronym stands for have changed a couple of times along the way!

jcranmer 7y ago

JMAP is pretty explicitly meant to replace IMAP. IMAP was originally conceived essentially to allow a very thin client that proxies every user command back to the user store, and it also embeds some reliance on old implementation artifacts (UIDVALIDITY, anyone?). There are a lot of "fun" corner cases--I once found a message that was interpreted 5 different ways by 4 different implementations. (It doesn't help that MIME structure is actually pretty loopy and maps very poorly to how all modern clients view mail messages, resulting in many interesting interpretations). Modern email clients are all structured very differently from the "thin client" perspective--everyone keeps their own copy of the email (metadata) database locally, and use IMAP essentially as a database synchronization protocol, but IMAP is pretty bad at synchronization, at least until the LEMONADE additions came in ~a decade ago. IMAP is especially bad at handling multiple folders correctly, since it assumes that every folder is independent of the other ones, and you can only sit and wait for messages on one folder per connection at a time.