Yeah, what can't be fixed by shoveling JSON shit into HTTP instead of a dedicated protocol?
JMAP was stupid when the Fastmail CEO or whoever was here pushing it, and it's still stupid.
JMAP was stupid when the Fastmail CEO or whoever was here pushing it, and it's still stupid.
Replacing it with something more sane seems like a good use of time.
> There are libraries for every single language imaginable.
These statements are contradictory.
[no application protocol implementer] implements HTTP, JSON, and TLS [because there are well-worn implementations that can just be used for the purpose].
I'd challenge you to find a single production suitable language which _doesn't_ have a http library.
Similarly, HTTP is a big standard that takes a long time to implement well. But very few people will have to implement it: they will use existing implementations.
This results in making it extraordinarily easy to break most parsers in use, today. For example, to kill Python:
n="$(python3 -c 'import math; import sys; sys.stdout.write(str(math.floor(sys.getrecursionlimit() - 4)))')"
left="$(yes [ | head -n "$n" | tr -d '\n')"
echo "$left" | python3 -c 'import json; print(json.loads(input()))'
So when you're handling something like email, on a mobile device which may drop a partial connection, you need a hell of a lot of extra work to show the partial download, which might even be everything except the closing braces, or you have to discard the whole thing - which isn't kind to your user.
Even so, parsing JSON is a well-understood problem, and there are tons of mature libraries to parse and generate it. I'd much rather work with a JSON-based protocol than one which made up its own wacky data format.
The same goes for the use of HTTP. It may not be the ideal protocol for accessing mail, but everyone knows how to work with HTTP, and tools to interact with it are plentiful.
The same could easily be said for mbox and maildir. These have been around forever, and if you have a library for JSON, you've probably got a library for those two, as well. But parsing them tends to be less error-intensive if you hit some kind of connection interruption.
The complaint for JSON in JMAP tends to come down to - does it improve the current status quo?
Never heard of the ">From" problem? :)
mbox has a well-documented escaping problem -- many tools which parse mbox files will mistake a line which begins with the word "from" for the start of a new message. As a result, many tools which generate mbox data will insert a ">" before the start of those lines, mangling the data slightly to prevent corruption.
But that's besides the point. mbox/maildir are data storage formats, not network protocols. The corresponding network protocols (POP and IMAP) have their respective problems as well, though.
Yes, they all have problems. That's... Our industry. You pick and choose your problems. Hence why it's easy to point out rough edges in JSON, and it's easy with mbox or maildir, too.
Do you have multiple high quality implementations for supporting mbox or maildir in nearly every language and framework in active use today?
If not, then they’re nothing like JSON.
Yes.
They're builtin to Python's stdlib [0]. There's dozens for JS. Part of the PHP stdlib. [1] A number for Rust. Several for Go. And so on, and so forth.
[0] https://docs.python.org/3/library/mailbox.html
[1] https://www.php.net/manual/en/function.imap-createmailbox.ph...
That's an IMAP library, not mbox/maildir, and it's part of an extension, not the standard library.
JSON is a data exchange format, it’s always been intended as a way to communicate between systems. You can use it for data storage just fine, but it’s not the primary role of the format.
Mbox was not designed as an exchange / interchange format, but as a storage format for MUA, with some possibility of interoperability.
> so special parsers are not needed: this is quite intentional.
Two lines from a song rjbs and I made (but never published) about JMAP a few years ago, back when I was a Fastmail employee, set to the tune of the Major-General’s Song.
It's a diseased mind that takes a shitty programming language, JavaScript, and turns it into a shitty structured data format.
But probably not because it adds an other layer of friction and complexity to deployment, which doesn’t do much good to your odds.
And it requires an entire additional ecosystem of inspection and protection capabilities to appear.
Not to mention the parsing and serialisation of a bespoke protocol, and the risk of all the usual framing and escaping errors in the protocol.
It also requires going to Iana for a port.
Except it isn't. As you say, IMAP could do with modernisation; JMAP isn't that, it's a replacement.
If you want to replace a protocol that's in very widespread use, then your replacement needs to offer decisive benefits to operators and users, otherwise they won't switch. JMAP seems to offer benefits only to developers.
In theory that's doable. In practice modernizing a protocol with extensions is though, since support ends up patchy. Especially when the big email providers have few reasons to make a documented, non-propriety extension. Why would they when they can instead push people to their propriety apps?
It's definitely possible that JMAP doesn't catch on. In that case, we'll probably just keep languishing with non-modernised IMAP.
The key is getting client support, especially in mobile (where there is a noticeable user benefit) and in open source software.
I find this argument shortsighted. If it benefits developers then it does benefit users. Making developers' lives easier means they produce code faster (users like things done sooner), have fewer bugs in their code (users don't like buggy code), and have more time to implement other features (users like featureful software). I don't see how that doesn't benefit users.
I've spent a lot of time on it, but the reasons that JMAP was developed still exist and are still valid :)