←back to thread

JMAP for Calendars, Contacts and Files Now in Stalwart

(stalw.art)
309 points StalwartLabs | 5 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 #
WorldMaker ◴[22 Oct 25 19:29 UTC] No.45673994[source]▶
> binary protocol

Email was never a binary protocol. Notoriously so, it's why MIME types and MIME encodings get so complicated.

Most of the "old internet" protocols (email, FTP, even HTTP itself) were bootstrapped on top of built-mostly-for-plaintext Telnet. HTTP as the new telnet has a bunch of improvements when it comes to binary data, request/response-based data flows, and some other considerations. HTTP/3 is even inherently a binary protocol, it's lack of "telnet-compatibility" one of the concerns about switching the majority of the web to it.

vCard/vCal/iCard/iCal were also deeply "plaintext formats". JSON is an improvement because it is more structured, even more efficient, than those predecessors. JSON may not look efficient, but it compresses extremely well and can be quite efficient in gzip and Brotli streams.

I feel like "JSON over HTTP" is a subtle improvement over "custom text formats over telnet", even if it doesn't sound like "binary protocol efficiency" at first glance. Especially as HTTP/3 pushes HTTP more efficient and more "binary", and arguably "more fundamental/basic" with HTTP/3 even taking over more roles in the TCP/UDP layer of the internet stack. (Telnet would never try to replace TCP.) HTTP isn't the worst bootstrap layer the internet could use to build new protocols and apps on top of. Sure, it would be neat to see more variety and experiments outside of the HTTP stack, too, but HTTP is too useful at this point not to build a bunch of things on top of it instead of as their own from-scratch protocol.

replies(6): >>45674072 #>>45674139 #>>45675430 #>>45675548 #>>45675668 #>>45676137 #
1. zzo38computer ◴[22 Oct 25 21:57 UTC] No.45675668[source]▶
> Notoriously so, it's why MIME types and MIME encodings get so complicated.

I made up ULFI because I thought MIME has some problems.

> JSON may not look efficient

Efficiency is not the only issue; there is also the consideration of e.g. what data types you want to use. JSON does not have a proper integer type, does not have a proper binary data type (you must encode it as hex or base64 instead), and is limited about what character sets can be used.

(Also, like other text formats, escaping will be needed.)

> I feel like "JSON over HTTP" is a subtle improvement over "custom text formats over telnet"

I think it can be, depending on the specific use; sometimes it isn't, and will make it worse. (HTTP does have the advantage of having URLs and virtual hosting, although I think it adds too much complexity more than should be needed.) However, I still think that DER is generally better than JSON.

> HTTP isn't the worst bootstrap layer the internet could use to build new protocols and apps on top of.

I think it depends on the specific application. However, even then, I think there are better ways than using HTTP with the complexity that it involves, most of which should not be necessary (even though a few parts are helpful, such as virtual hosting).

replies(1): >>45675977 #
2. dotancohen ◴[22 Oct 25 22:29 UTC] No.45675977[source]▶

  > JSON does not have a proper integer type
What are the drawbacks to using the JavaScript Number (really a double float I think) datatype as an integer in an object representation language such as JSON? I've never seen a use case where e.g. 42 (int) could be confused with 42.0 (float). If your application needs specifically an int or a float, then the ingesting application knows that.

If the answer is monetary values, then those should never be floats, and should not be represented in JSON as such. E.g. a dollar and a half should be represented as 150 cents. This follows even for sub-cent precision.

replies(3): >>45676282 #>>45677914 #>>45678201 #
3. zzo38computer ◴[22 Oct 25 23:05 UTC] No.45676282[source]▶
I don't mean 32-bit integers, but rather, 64-bit (and sometimes bigger) integers. JSON already works OK for 32-bit integers (although it is not ideal).
4. RedShift1 ◴[23 Oct 25 03:37 UTC] No.45677914[source]▶
Much easier would just be native decimal support in JS and we can represent a decimal using d as the decimal point, for example 15d0 (15.0) or 384d25 (384.25).

Using cents instead of dollars sounds fine until you have to do math like VAT, you really need decimal math for that.

5. cstrahan ◴[23 Oct 25 04:36 UTC] No.45678201[source]▶
JSON numbers are not JavaScript Numbers.

While the grammar is specified (that’s what JSON is, after all), the runtime representation is unspecified. A conformant JSON parser can parse “1” as 1.0. They can be backed by doubles, or singles, or arbitrary precision.