4 ms·

> JMAP is not designed around a persistent network socket, so it’s perfect for webmail clients that connect, do stuff, then disconnect (which is exactly NOT how

> JMAP is not designed around a persistent network socket, so it’s perfect for webmail clients that connect, do stuff, then disconnect (which is exactly NOT how IMAP is supposed to be used) WTF? So, webmail was limited by the fact that it was running in a browser and thus had to use HTTP, which has semantics that don't really fit the needs of an email access protocol. Now, we do have stuff like websockets that would make it possible to run a protocol from the webmail client that actually fits the needs, and instead people invent a new protocol that inherently doesn't match the needs of the application?

majewsky 8y ago
Most mail clients are running on mobile (judging by number of devices). Long-running connections on mobile are a bad idea because of network reliability and battery concerns.
- zAy0LfpBZLC8mAC 8y ago
  Hu? Constantly establishing new connections saves power vs. maintaining one estalished connection? Could you explain how that works? 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?
  - amaranth 8y ago
    > Constantly establishing new connections saves power vs. maintaining one estalished connection? Could you explain how that works? 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.
    - zAy0LfpBZLC8mAC 8y ago
      Sorry, but that makes no sense. Keeping a TCP connection in established state does not require any modem to be powered. I even suspend my laptop with established SSH connections over night, to disk, so it's completely powered off, I could even disconnect the power supply and take out the battery for the night. When I power it back on, the SSH sessions are still working perfectly fine, after hours of being powered down, and that is completely unsurprising, given how TCP works. 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.
      - detaro 8y ago
        That does not work over arbitrary connections, especially not mobile ones: in many cases, long-running connections are terminated (either because a moving phone moved in the network and received a new address, or because a middlebox threw away state about a connection it hasn't seen traffic for in x minutes). If you shut the modem down, you also can not receive messages, so you can only use polling patterns anyways (at which point the benefit of e.g. Websockets is largely lost). 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.
        zozbot123 8y ago
        > 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 FWIW this would happen quite naturally if the system simply used flexible timers for these sorts of wakeups. It's an accepted, even trivial solution to the "need to power something up on an infrequent and perhaps unpredictable basis, and have it be used seamlessly by multiple apps" use case. Centralized services are nice but they shouldn't be the only way for a system to get notified about stuff.
  - miracle2k 8y ago
    Webmail was limited by HTTP, but not because HTTP is stateless; rather, it's because no mail server speaks HTTP, which means every webmail has to implement it's own IMAP proxy, 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. On the other hand, JMAP does allow you to get push notifications on changes, outside of the normal HTTP API.
    - zAy0LfpBZLC8mAC 8y ago
      > Webmail was limited by HTTP, but not because HTTP is stateless; rather, it's because no mail server speaks HTTP, which means every webmail has to implement it's own IMAP proxy 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?
      - miracle2k 8y ago
        You obviously disagree, but JMAP made exactly the right choice: A simple, pull based protocol, with a side-channel for notifications. It's not clear why anyone would want a complex websockets-based monstrosity when the simple approach solves the problem perfectly. 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.
  - toast0 8y ago
    Ignoring efficiency concerns, modern mobile oses don't allow applications to keep connections open for long. If you want notifications to work, you need to use the platform notification system. 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)
    - zAy0LfpBZLC8mAC 8y ago
      Well, yeah, if you are very optimistic and generous. In reality, this is yet another way of the manufacturers maintaining power over their customers' property. After all, there is zero reason why any of those things would require them as a middle-man, they could just invent a protocol for that and/or provide a library and a system service on the device that allow applications to maintain a background connection without the need to involve them in any way on the network/server side. The only useful involvement they could have might be providing endpoints for measuring and exchanging NAT timeout information for providers, maybe. 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.

majewsky 8y ago

Most mail clients are running on mobile (judging by number of devices). Long-running connections on mobile are a bad idea because of network reliability and battery concerns.

zAy0LfpBZLC8mAC 8y ago
Hu? Constantly establishing new connections saves power vs. maintaining one estalished connection? Could you explain how that works? 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?
- amaranth 8y ago
  > Constantly establishing new connections saves power vs. maintaining one estalished connection? Could you explain how that works? 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.
  - zAy0LfpBZLC8mAC 8y ago
    Sorry, but that makes no sense. Keeping a TCP connection in established state does not require any modem to be powered. I even suspend my laptop with established SSH connections over night, to disk, so it's completely powered off, I could even disconnect the power supply and take out the battery for the night. When I power it back on, the SSH sessions are still working perfectly fine, after hours of being powered down, and that is completely unsurprising, given how TCP works. 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.
    - detaro 8y ago
      That does not work over arbitrary connections, especially not mobile ones: in many cases, long-running connections are terminated (either because a moving phone moved in the network and received a new address, or because a middlebox threw away state about a connection it hasn't seen traffic for in x minutes). If you shut the modem down, you also can not receive messages, so you can only use polling patterns anyways (at which point the benefit of e.g. Websockets is largely lost). 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.
      - zozbot123 8y ago
        > 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 FWIW this would happen quite naturally if the system simply used flexible timers for these sorts of wakeups. It's an accepted, even trivial solution to the "need to power something up on an infrequent and perhaps unpredictable basis, and have it be used seamlessly by multiple apps" use case. Centralized services are nice but they shouldn't be the only way for a system to get notified about stuff.
- miracle2k 8y ago
  Webmail was limited by HTTP, but not because HTTP is stateless; rather, it's because no mail server speaks HTTP, which means every webmail has to implement it's own IMAP proxy, 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. On the other hand, JMAP does allow you to get push notifications on changes, outside of the normal HTTP API.
  - zAy0LfpBZLC8mAC 8y ago
    > Webmail was limited by HTTP, but not because HTTP is stateless; rather, it's because no mail server speaks HTTP, which means every webmail has to implement it's own IMAP proxy 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?
    - miracle2k 8y ago
      You obviously disagree, but JMAP made exactly the right choice: A simple, pull based protocol, with a side-channel for notifications. It's not clear why anyone would want a complex websockets-based monstrosity when the simple approach solves the problem perfectly. 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.
- toast0 8y ago
  Ignoring efficiency concerns, modern mobile oses don't allow applications to keep connections open for long. If you want notifications to work, you need to use the platform notification system. 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)
  - zAy0LfpBZLC8mAC 8y ago
    Well, yeah, if you are very optimistic and generous. In reality, this is yet another way of the manufacturers maintaining power over their customers' property. After all, there is zero reason why any of those things would require them as a middle-man, they could just invent a protocol for that and/or provide a library and a system service on the device that allow applications to maintain a background connection without the need to involve them in any way on the network/server side. The only useful involvement they could have might be providing endpoints for measuring and exchanging NAT timeout information for providers, maybe. 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.