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

JMAP: A modern, open email protocol

ietf.org

Post reply on HN
Print view View original

111–120 of 120 posts

Re: JMAP: A modern, open email protocol

#111

Post by vbezhenar »

afiori wrote: post #107
vbezhenar wrote: post #106

Earlier quoted context omitted.

The hardest thing with HTTP is to send server-initiated messages to client. There are multiple approaches (websockets, SSE, client polling) but they are not simple. Also HTTP carries some overhead. It's not significant, something like 50-100 bytes, but it might matter for a lot of tiny messages, I guess. Another factor is: those intermediate proxies might break your app. They might cache your responses even if you do…

> The hardest thing with HTTP is to send server-initiated messages to client. My (weak) understanding here is that in most mobile cases this is intrinsically problematic and is the reason for the plethora of push notification standards. In this case HTTP is more battery friendly as a noisy server can't as easily spam your phone with traffic.

HTTP can't be more mobile friendly, since it's exactly the same TCP connection for iOS, there's nothing special about it. You might design mobile-friendly protocol which would leverage proprietary push messages, but that's HTTP-agnostic as well.

I mean, if you need to spam your phone with traffic, you'll do that. If you're writing whatsapp, you want to deliver messages instantly if user has app opened, so you'll keep TCP connection to the server.

Re: JMAP: A modern, open email protocol

#112

Post by atesti »

tracker1 wrote: post #97
btown wrote: post #47

Earlier quoted context omitted.

However bad this is, it's better than a plethora of non-interoperable optional IMAP extensions! https://developers.google.com/gmail/imap/imap-extensions

Sigh... this is why implementing IMAP is a beast... Also doesn't cover what Exchange/Office 365 adds to the mix. I'm happy to see a newer standard that is at least simpler to understand and implement.

Unfortunately Exchange adds almost nothing to the mix, they support only a bare minimum of imap extensions (only literal+ if i remember correctly) and much stuff is not supported

Re: JMAP: A modern, open email protocol

#113

Post by afiori »

vbezhenar wrote: post #111
afiori wrote: post #107

Earlier quoted context omitted.

> The hardest thing with HTTP is to send server-initiated messages to client. My (weak) understanding here is that in most mobile cases this is intrinsically problematic and is the reason for the plethora of push notification standards. In this case HTTP is more battery friendly as a noisy server can't as easily spam your phone with traffic.

HTTP can't be more mobile friendly, since it's exactly the same TCP connection for iOS, there's nothing special about it. You might design mobile-friendly protocol which would leverage proprietary push messages, but that's HTTP-agnostic as well. I mean, if you need to spam your phone with traffic, you'll do that. If you're writing whatsapp, you want to deliver messages instantly if user has app opened, so you'll keep…

I was referring to the low power optimizations like doze in android, where the OS tries to schedule together many actions so to minimize the time the radio is on. In this case the OS can optimize HTTP connections (if you use the OS's HTTP library) better that a bare TCP. (this does not apply if you handle HTTP internally)

Re: JMAP: A modern, open email protocol

#114

Post by flukus »

crest wrote: post #92
flukus wrote: post #72

Looking at the request it contains properties like collapseThreads and sort, moving this sort of functionality server side is a regression. This is an API for hosted services, it's disingenuous to compare it to imap.

Do you see anything that should (or could) be done via IMAP but not via JMAP? Adding support for higher level operations to the protocol can be worth the complexity if it removes network roundtrips. Not everyone is lucky enough to have a reliable, fast, low latency link to his IMAP server.

> Not everyone is lucky enough to have a reliable, fast, low latency link to his IMAP server.

This is a protocol from the 80's, I'm sure it doesn't require anything we'd consider a fast connection today, latency may have changed though, mail servers used to be geographically closer.

> Adding support for higher level operations to the protocol can be worth the complexity if it removes network roundtrips.

It also benefits SaaS providers by having the complexity on their end and potentially limits apps. In my example of "collapseThreads" why does this need to be an option at all instead of something like "parentId" and leaving it up to the client?

More features also means more ways to abuse them, imagine google saying "yes we support JMAP in gmail" then ignoring certain features.

Re: JMAP: A modern, open email protocol

#115

Post by Aeolun »

contingencies wrote: post #78
Aeolun wrote: post #74

Earlier quoted context omitted.

Did you consider that they might only be wasting your time? I haven’t ever felt any frustration at any of the things you named.

Both are standard features on GMail, which beats your sample size of 1.

I’m not sure how sample size one beats sample size one.

Did you interview all gmail users to ask them if they would miss those features if they weren’t there?

Re: JMAP: A modern, open email protocol

#116

Post by afiori »

flukus wrote: post #114
crest wrote: post #92

Earlier quoted context omitted.

Do you see anything that should (or could) be done via IMAP but not via JMAP? Adding support for higher level operations to the protocol can be worth the complexity if it removes network roundtrips. Not everyone is lucky enough to have a reliable, fast, low latency link to his IMAP server.

> Not everyone is lucky enough to have a reliable, fast, low latency link to his IMAP server. This is a protocol from the 80's, I'm sure it doesn't require anything we'd consider a fast connection today, latency may have changed though, mail servers used to be geographically closer. > Adding support for higher level operations to the protocol can be worth the complexity if it removes network roundtrips. It also benef…

> This is a protocol from the 80's, I'm sure it doesn't require anything we'd consider a fast connection today,

But it does require long lasting stable connections, which is what you want to avoid on a mobile that tries to connect for only a few second at a time and the go back to low-power mode.

Re: JMAP: A modern, open email protocol

#117

Post by tialaramex »

viraptor wrote: post #82
tialaramex wrote: post #30

Earlier quoted context omitted.

The IETF's standardisation process almost can't help but improve whatever it is you're trying to standardize. Not only are you being shepherded by peers with expertise in whatever corner of networking you're excited about (the Area Directors for whichever Area your Working Group was assigned to) but you're obliged to put up with anyone who cares to offer an opinion mailing it in. Looking for consensus isn't a good wa…

> IETF's standardisation process almost can't help but improve whatever it is you're trying to standardize I've read the SIP RFCs. That's not a hard rule unfortunately. (Unless it really was worse before, but I can't imagine that...)

No need to imagine, the IETF process results in a series of drafts for relatively modern things like SIP, so you can go back and look e.g.

https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=rfc326...

... is the changes from their last draft to the published RFC

Admittedly only very recent work with git-minded people in the WG has a full git history of revisions, earlier work like SIP just has the numbered drafts representing a few months work typically from one draft to the next, but you can go back and see this work and also the mailing lists that drove the changes.

I'm not a SIP expert, but looks to me like the brief extracts I read are improvements. For example that last draft requires people who want to add a new SIP method (like INVITE or CANCEL) to send IANA a copy of the RFC describing their method. Why? What possible purpose could there be when RFCs are public documents? Are they expected to... print it out and mail it? So, the final standard text just says to provide the RFC number.

Re: JMAP: A modern, open email protocol

#119

Post by westurner »

lucideer wrote: post #53
westurner wrote: post #28

What are the optimizations in JMAP that make it faster than, say, Solid? Solid is built on a bunch of W3C Web, Security, and Linked Data Standards; LDP: Linked Data Protocol, JSON-LD: JSON Linked Data, WebID-TLS, REST, WebSockets, LDN: Linked Data Notifications. [1][2] Different worlds, I suppose. There's no reason you couldn't represent RFC5322 data with RDF as JSONLD. There's now a way to do streaming JSON-LD. LDP…

I would say your comment, and the first reply, both demonstrate quite effectively why JMAP is probably a better choice for email. > It may or may not (yet?) be as efficient for synchronization as JMAP, but it's definitely designed for all types of objects If we hypothetically allow for equal adoption & mindshare of both, and assume both are non-terrible designs, I'd guess the one designed for "all types of objects" i…

> If we hypothetically allow for equal adoption & mindshare of both, and assume both are non-terrible designs, I'd guess the one designed for "all types of objects" is less likely to ever be as efficient as the one designed with a single use-case in mind.

This is a generalization that is not supported by any data.

Standards enable competing solutions. Competing solutions often result in performance gains and efficiency.

Hopefully, there will be performant implementations and we won't need to reinvent the wheel in order to synchronize and send notifications for email, contacts, and calendars.

Re: JMAP: A modern, open email protocol

#120

Post by westurner »

dragonne wrote: post #44
westurner wrote: post #28

What are the optimizations in JMAP that make it faster than, say, Solid? Solid is built on a bunch of W3C Web, Security, and Linked Data Standards; LDP: Linked Data Protocol, JSON-LD: JSON Linked Data, WebID-TLS, REST, WebSockets, LDN: Linked Data Notifications. [1][2] Different worlds, I suppose. There's no reason you couldn't represent RFC5322 data with RDF as JSONLD. There's now a way to do streaming JSON-LD. LDP…

> There's no reason you couldn't represent RFC5322 data with RDF as JSONLD. There's now a way to do streaming JSON-LD. Is there a reason you'd want to? I clicked all your links but I still have no idea what Solid is.

To eliminate the need for domain-specific parser implementations on both server and client, make it easy to index and search this structured data, and to link things with URIs and URLs like other web applications that also make lots of copies.

Solid is a platform for decentralized linked data storage and retrieval with access controls, notifications, WebID + OAuth/OpenID. The Wikipedia link and spec documents have a more complete description that could be retrieved and stored locally.

Post reply on HN