←back to thread

JMAP for Calendars, Contacts and Files Now in Stalwart

(stalw.art)
316 points StalwartLabs | 1 comments | 22 Oct 25 17:26 UTC | HN request time: 0s | source
Show context
9dev ◴[22 Oct 25 18:50 UTC] No.45673491[source]▶
While JMAP seems to scratch every itch of a sucker for proper web API design, I’m wondering if the design space for new protocols should really be constrained to layers on top of HTTP. Is there really any new-ish binary protocol these days? Stuff like file sharing or groupware, mail, calendars, and so on—these things could be a lot more efficient and don’t really need the overhead of JSON as the message interchange format, IMHO. Then again, a lot of solid thinking went into these things, so there probably are a lot of good reasons that I’m not aware of.

Still, it’s an interesting space, I think.

replies(8): >>45673994 #>>45674417 #>>45675659 #>>45675911 #>>45676495 #>>45676769 #>>45677107 #>>45678657 #
1. toomim ◴[23 Oct 25 00:15 UTC] No.45676769[source]▶
> Is there really any new-ish binary protocol these days?

HTTP/2 and HTTP/3 are binary protocols. And if you replace the JSON with CBOR, then even the payload becomes binary.

The reason for using HTTP is that the semantics are right. HTTP is a state transfer protocol, and ultimately, that's 90% of what you need for sync.

The other 10% is for subscriptions, updates, with versioning, and patches. You can get these by adding the Braid extensions (see braid.org) which upgrade HTTP from a state transfer to a state synchronization protocol. (I work on Braid.)