3 ms·

Being a stateless protocol is the big one, for mobile. There’s more: https://fastmail.blog/2014/12/23/jmap-a-better-way-to-email/ https://fastmail.blog/2014/12/

by vsl 6y ago

Being a stateless protocol is the big one, for mobile. There’s more: https://fastmail.blog/2014/12/23/jmap-a-better-way-to-email/ https://fastmail.blog/2014/12/23/jmap-a-better-way-to-email/

saurik 6y ago
That "stateless" paragraph in that article is explicitly referring to the per-connection message identifiers I was referring to; but that state burden is mostly carried by the server (which is put in the awkward position of dealing with separate clients with individual state sharing a mailbox) not the client (which by definition has a unique state anyway), which the article even admits. I will argue that if you use the right data structures--not that anyone does--it really isn't that hard to make that work on the server, and the benefits to the client are actually enormous... particularly on mobile! The way IMAP handles message identifiers allows for the client to pretend to manage a ridiculously large list of messages without storing any state locally that isn't visible on the screen (like it is _so good at this_ as Mark Crispin seriously intended the original IMAP protocol to be used by thin clients for mail: synchronizing mail over IMAP was never the intended usage model), as the entire problem of managing that consistent view has been pushed to the server (where it is solvable, just no one cares enough to even do a basic implementation correct much less a good one as everyone misunderstands and detests IMAP). FWIW, the argument for how JMAP supports update batching over push notification channels is in fact interesting for mobile clients :(. That is so totally the fault of the mobile networks and OS people, though :(. The correct solution for that is to provide a flow control layer for wireless IP, at which point every app could be doing its own end-to-end encrypted push notification stuff without having to go through Apple/Google, but the incentive structure to centralize notifications through a middleman was just too great :/.
- afiori 6y ago
  > push notification... That is so totally the fault of the mobile networks and OS people The issue for mobile is that unrestricted push notifications are a serious battery drain. I think that JMAP makes the correct choice here, a push notification is just an external action/url, how the notification is delivered to the human is left out of the protocol. I would say that it allows for both openness and centralization without a bias for one or the other.
  - saurik 6y ago
    Yes, I both understood that, acknowledged it, and then not only noted that a better solution was available but actually sketched how that better solution would work ;P. Given the poor incentives on the platform players here, I will thereby repeat the part where I understand and acknowledge the issue, but am going to then once again note how sad I am that we are in a world that didn't just solve this issue in an egalitarian way that doesn't require middle-man (using a flow control layer for wireless IP, rather than simulating that using an oligopoly of middle boxes).
    - afiori 6y ago
      oh, the reason for my answer is that I implicitly assumed that something like `a flow control layer for wireless IP` capable of solving the problem could not exist. Or better I cannot even imagine how it could work. My understanding is that a important property is that the device does not receive network packets that are not "replies". So that it has control on when it is fine to power down the network (in a very gross simplification) So maybe something like what you are describing would be a protocol where the client can say "pin me back with this for this category of events but no sooner than X minutes", but at a network level, like a tagged TCP sleep function. I never thought of this possibility. In the form I have imagined it it is technically inferior, but it would be an interesting approach to decentralization and surely could be improved.

by vsl 6y ago

Being a stateless protocol is the big one, for mobile. There’s more: https://fastmail.blog/2014/12/23/jmap-a-better-way-to-email/ https://fastmail.blog/2014/12/23/jmap-a-better-way-to-email/

saurik 6y ago

That "stateless" paragraph in that article is explicitly referring to the per-connection message identifiers I was referring to; but that state burden is mostly carried by the server (which is put in the awkward position of dealing with separate clients with individual state sharing a mailbox) not the client (which by definition has a unique state anyway), which the article even admits. I will argue that if you use the right data structures--not that anyone does--it really isn't that hard to make that work on the server, and the benefits to the client are actually enormous... particularly on mobile! The way IMAP handles message identifiers allows for the client to pretend to manage a ridiculously large list of messages without storing any state locally that isn't visible on the screen (like it is _so good at this_ as Mark Crispin seriously intended the original IMAP protocol to be used by thin clients for mail: synchronizing mail over IMAP was never the intended usage model), as the entire problem of managing that consistent view has been pushed to the server (where it is solvable, just no one cares enough to even do a basic implementation correct much less a good one as everyone misunderstands and detests IMAP). FWIW, the argument for how JMAP supports update batching over push notification channels is in fact interesting for mobile clients :(. That is so totally the fault of the mobile networks and OS people, though :(. The correct solution for that is to provide a flow control layer for wireless IP, at which point every app could be doing its own end-to-end encrypted push notification stuff without having to go through Apple/Google, but the incentive structure to centralize notifications through a middleman was just too great :/.

afiori 6y ago
> push notification... That is so totally the fault of the mobile networks and OS people The issue for mobile is that unrestricted push notifications are a serious battery drain. I think that JMAP makes the correct choice here, a push notification is just an external action/url, how the notification is delivered to the human is left out of the protocol. I would say that it allows for both openness and centralization without a bias for one or the other.
- saurik 6y ago
  Yes, I both understood that, acknowledged it, and then not only noted that a better solution was available but actually sketched how that better solution would work ;P. Given the poor incentives on the platform players here, I will thereby repeat the part where I understand and acknowledge the issue, but am going to then once again note how sad I am that we are in a world that didn't just solve this issue in an egalitarian way that doesn't require middle-man (using a flow control layer for wireless IP, rather than simulating that using an oligopoly of middle boxes).
  - afiori 6y ago
    oh, the reason for my answer is that I implicitly assumed that something like `a flow control layer for wireless IP` capable of solving the problem could not exist. Or better I cannot even imagine how it could work. My understanding is that a important property is that the device does not receive network packets that are not "replies". So that it has control on when it is fine to power down the network (in a very gross simplification) So maybe something like what you are describing would be a protocol where the client can say "pin me back with this for this category of events but no sooner than X minutes", but at a network level, like a tagged TCP sleep function. I never thought of this possibility. In the form I have imagined it it is technically inferior, but it would be an interesting approach to decentralization and surely could be improved.