Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JMAP for Calendars, Contacts and Files Now in Stalwart

stalw.art

Post reply on HN
Print view View original

81–90 of 204 posts

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#81

Post by p_l »

cyberax wrote: post #39
p_l wrote: post #16

Earlier quoted context omitted.

A lot of the textual nature of older IETF protocols, including the CR LF line endigns, can be probably traced to how easy it was to bang out a bad implementation full of subtle problems that could be debugged by sitting an undergrad student at a teletype instead of spending time on having some binary serializer (that telecom companies definitely had money for)

It's also a reflection of the state-of-the-art at the time. Binary protocols were an unmitigated disaster, with standards bodies thinking that applying to the ISO for your organizational ID is a perfectly fine step that anyone does anyway.

That's why there was an entire section for unassigned numbers.

Binary protocols just meant you actually needed to implement serialiser/deserialiser and similar tooling instead of writing dumbest possible riff on strtok() and hoping your software won't be used anymore once DoD internet becomes mature

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#82

Post by raybb »

Does it seem like the calendar protocol will be able to replace the VTODO bit of ical so that Todo applications can be built on top of it? I've played around with ics files a bit for the tasks app in nextcloud and it wasn't a pleasant experience so I kinda dropped the project.

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#83

Post by 7bit »

WorldMaker wrote: post #13
9dev wrote: post #6

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 f…

> 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…

> Most of the "old internet" protocols (email, FTP, even HTTP itself) were bootstrapped on top of built-mostly-for-plaintext Telnet.

That's just not true. Telnet and SMTP are built on top of TCP. They live on the same layer. They were originally both protocols that transmitted data with printable ascii, hence why they look similar. There are many other protocols like Telnet and SMTP that worked like that, auch as nntp, irc, and yes, even http.

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#84

Post by blacklion »

What next? Replacing Sieve with something cumbersome, but JSON based?

There is no good desktop implementation of MUA with old technologies (IMAP, Sieve), will all this JMAP help?

I don't think so.

What is profit to have good server with new good (assume it is good, I'm not sure, but lets assume) protocols without good client?

IMAP4 is underused by modern clients: it allows to effectively store client configuration on server, nobody implements it on client side. It allows to configure per-folder Sieve scripts, nobody implements it on client side. Nobody implements good Sieve client (with folder name autocomplition and such) even for global script, not to mention per-folder ones. Heck, there is no good Sieve editor! (I know about Sieve client built on Electron, it is not good, it is incomplete and buggy).

Servers are solved problem (sendmail, exim, postfix, dovecot, cyrus). Clients are not, they stagnated at the moment GMail was announced.

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#85

Post by p_l »

9dev wrote: post #63
WorldMaker wrote: post #13

Earlier quoted context omitted.

> 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…

It’s not that I cannot appreciate the improvements in the space, I’m just wondering if there might be a big part of the design space for widely used protocols that ends up unexplored because the default for almost anything now is HTTP. It has basically become OSI layer 8 at this point.

MIME/Content-Negotiation is essentially OSI Presentation Layer

HTTP sorta acts as stump of ROSE with bit of ACSE. In addition it provides a bit of basic layer for passing some extra attributes that might be considered in-band or out (or side?) band to the actual exchange.

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#86

Post by zzo38computer »

dotancohen wrote: post #78
zzo38computer wrote: post #68

Earlier quoted context omitted.

> 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…

> 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…

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).

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#87

Post by mmooss »

blacklion wrote: post #84

What next? Replacing Sieve with something cumbersome, but JSON based? There is no good desktop implementation of MUA with old technologies (IMAP, Sieve), will all this JMAP help? I don't think so. What is profit to have good server with new good (assume it is good, I'm not sure, but lets assume) protocols without good client? IMAP4 is underused by modern clients: it allows to effectively store client configuration on…

> What is profit to have good server with new good (assume it is good, I'm not sure, but lets assume) protocols without good client?

You need both. You could say, what profit is a good client without a server? By that reasoning, we never stake a step forward without a complete solution.

Now a better mail implementation is just a client away.

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#88

Post by mmooss »

mjrpes wrote: post #66
woodruffw wrote: post #27

Earlier quoted context omitted.

Serious question: what’s the differentiator if major email providers don’t support it? (This should not be interpreted as a defense of IMAP.)

One big differentiator is JMAP allows one network connection to track new emails that may get delivered across different folders. With IMAP you need a connection open for each folder.

Why is that necessarily a good thing? If there's a problem with one folder - or just a large email - all are delayed?

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#89

Post by kilburn »

mjrpes wrote: post #66
woodruffw wrote: post #27

Earlier quoted context omitted.

Serious question: what’s the differentiator if major email providers don’t support it? (This should not be interpreted as a defense of IMAP.)

One big differentiator is JMAP allows one network connection to track new emails that may get delivered across different folders. With IMAP you need a connection open for each folder.

Implementing IMAP NOTIFY [1] would be a simpler path assuming you have IMAP implemented already though.

[1] https://www.rfc-editor.org/rfc/rfc5465.html

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#90

Post by whatevaa »

woodruffw wrote: post #27
sylens wrote: post #21

We need better client support for JMAP. Apple Mail, Thunderbird, Outlook (as if), and so on. I'm surprised some of the smaller ones like Canary or Spark don't implement it as a product differentiator.

Serious question: what’s the differentiator if major email providers don’t support it? (This should not be interpreted as a defense of IMAP.)

IMAP is a shit protocol in general. Notably, email UIDs are not guaranteed to be static across sessions (aka, next time you connect they may be different), which is just straight up dumb. You IMAP client has to do a lot of workarounds just for this, which leads to gnarly bugs and inefficiences.
Post reply on HN