And could you also explain how constantly making new connections makes things work more reliably over unreliable links? Like, does that allow you to transfer data when the network link is down? Does the fact that inside the TLS/TCP connection data is transferred via HTTP instead of IMAP somehow make the TCP connection work better over lossy links?
It would seem to me like the exact opposite should be the case, if it has any effect at all?
The platform argument is roughly that if they hold open one connection, it's cheaper than each app holding open their own connection. And maybe, if you're optimistic, the platform will be better at figuring out ping intervals for that connection that adapt to broken Nat devices per network (ie: on some networks, wake up once a minute to keep the connection active, and on reasonable networks wake up once every 30 minutes)
But in any case, none of that is an argument for building a protocol that forces the problems that result from that on all platforms that don't have such restrictions, at best that is an argument in favor of workarounds to make things work as well as possible on such platforms.
Also, I would think that the long-term solution to this problem should be mobile link layer protocols that allow the mobile station to receive incoming packets with little delay while still conserving power. Stuff like high-powered, high SNR alert channels that allow the mobile station to shut down everything apart from a simple, low power, receiver, that only powers on for a few microseconds every few hundred milliseconds to listen for a wakeup signal from the network, so that incoming packets can be delivered with a latency of a few hundred milliseconds at any time. And then you are stuck with a stupid poll-based protocol that's adapted to the limitations of some ancient technology as a replacement for an even more ancient protocol that didn't have that limitation.
On the other hand, JMAP does allow you to get push notifications on changes, outside of the normal HTTP API.
That doesn't explain why it is limited, only why it isn't interoperable. A traditional IMAP client also didn't speak TLS. That wasn't a reason to invent a replacement for IMAP, because you simply stack IMAP on top of TLS, and noone complains that "every TLS IMAP server has to implement its own TLS proxy", let alone gets the idea that you should invent a replacement for IMAP in order to be able to use it over TLS.
> and IMAP as a protocol is very, very bad if you don't want to sync emails to your local machine and thus keep your own copy of the whole mailbox state.
Because? And mind you, we are looking for a reason that would justify (a) inventing a whole new protocol instead of adding a few small extensions and (b) specifically inventing a pull-based protocol that uses HTTP as the basis.
> On the other hand, JMAP does allow you to get push notifications on changes, outside of the normal HTTP API.
In other words: Because JMAP doesn't fit the needs of the application, because it uses a pull-based protocol, and in contrast to IMAP which has push built-in already (well, it's an extension to the original protocol, but one that is widely supported and a relatively simple change to the protocol), they support tacking on a workaround for the resulting problems? And that is supposed to be an argument for the protocol, or what?
I am not at all convinced that JMAP will succeed, I think it's along shot, but it's failure will not be because of the choice of HTTP.
If you maintain a connection you have a leave the modem powered. If you connect every so often (1 minute, 10 minutes, whatever) the modem can be powered down in between. The modem and the screen are the top two users of power in a phone so this is a big win.
The only thing that requires leaving the modem powered on is if you want to be able to receive something. But tearing down the connection obviously doesn't help with that. When the modem is powered down, you won't be able to receive anything more by not having an established TCP connection.
So, no, that does not explain how doing more work saves power.
So in practice, you have to regularly send traffic down the connection, fully powering up the modem, and ideally that shouldn't happen for each app individually. Now one could imagine a system where the OS coordinates this and signals to apps that the system is going to transmit now, and that they should trigger their own requests, bundling them in the process, but that's not how the platforms work. Instead, the choosen method is to have central push services, which the phone OS polls and then distributes the messages to the apps.
