4 ms·

Just to add to this point, I wanted to implement JMAP after only half completing an IMAP server implementation. Unfortunately, its just as bad only "this time w

by papaf 7y ago

Just to add to this point, I wanted to implement JMAP after only half completing an IMAP server implementation. Unfortunately, its just as bad only "this time with HTTP and Json". The batching advantages of JMAP could be generically done by using HTTP 2 and/or GraphQL.

chrismorgan 7y ago
I shall reply to your comment and your parent comment in one go here: I work on FastMail’s web interface, which is now based on JMAP. Here are my opinions on the matter. What papaf says is flatly not true. What andris9 says is generally unreasonable. At its core, the API part of JMAP is an RPC framework, with defined semantics for object synchronisation and querying. The most important part of it is those semantics, and they are necessarily more complex than what web developers are generally used to. Simple traditional-REST APIs or the likes of GraphQL lack those object synchronisation semantics altogether, and are wildly inferior for practical email clients. There is just no comparison at all. There is more to JMAP than just the API calls, though. What I think is the most obviously important part is that it also defines a push mechanism, including the ability for email clients to be notified of changes; this is tied into the object synchronisation semantics with the ability to ask questions like “what changed between these two states?”—so that your email client (be it on the web or not) can be told “something changed in the emails” and efficiently fetch the delta and apply it to the user interface and any persistent storage you may use. This is something that the shown WildDuck API does not appear to support at all, and is in fact something entirely unsupportable on such a style of API. These things are hard to do properly, in a way that will give any semblance of performance or efficiency. (It looks like WildDuck’s web interface does have some way arranged so that changes get pushed to the interface, but that doesn’t appear to be part of its public API, and I can’t imagine that it’s actually a good, flexible and efficient solution. I haven’t looked into how it is implemented at all, however. I’m open to discussion of what I’m confident will be its shortcomings, if you don’t like the aspersions I am casting.) Now to return to papaf’s remark: JMAP’s method batching is not achievable with HTTP/2 or GraphQL; the key difference is backreferences, whereby you can establish data dependencies between method calls, so that you pass part of one method call as an argument to subsequent method calls. To pick a common example of something that the FastMail web interface does, this allows you to express in one HTTP request the following: “find the first ten emails in Inbox, collapsing threads (so that you get one message from each thread only); then, given those, get the threads that they are in; then, given those threads, get the basic details of the emails that are contained in those threads.” In the absence of backreferences, you would need probably three round trips, or a special case in the API that limits flexibility. I will add that JMAP can be usefully combined with HTTP/2 so that you can issue multiple batches of requests simultaneously and use the results as they return. Please read through all the content on the front page of https://jmap.io/ https://jmap.io/. It provides good justification for why quite a few things are how they are. Remember this most important fact: JMAP is an object synchronisation protocol.
- Aeolun 7y ago
  Would it be best to wait to write a JMAP server until the spec is finalized? Or should I consider the current one mostly final? I’ve had one look at it and while the protocol looks really good, it also looks like I’d rather not implement it more than once ;)
  - chrismorgan 7y ago
    The spec is currently in the editor’s queue for publication. I believe that means that no further changes are anticipated.

by papaf 7y ago

chrismorgan 7y ago

I shall reply to your comment and your parent comment in one go here: I work on FastMail’s web interface, which is now based on JMAP. Here are my opinions on the matter. What papaf says is flatly not true. What andris9 says is generally unreasonable. At its core, the API part of JMAP is an RPC framework, with defined semantics for object synchronisation and querying. The most important part of it is those semantics, and they are necessarily more complex than what web developers are generally used to. Simple traditional-REST APIs or the likes of GraphQL lack those object synchronisation semantics altogether, and are wildly inferior for practical email clients. There is just no comparison at all. There is more to JMAP than just the API calls, though. What I think is the most obviously important part is that it also defines a push mechanism, including the ability for email clients to be notified of changes; this is tied into the object synchronisation semantics with the ability to ask questions like “what changed between these two states?”—so that your email client (be it on the web or not) can be told “something changed in the emails” and efficiently fetch the delta and apply it to the user interface and any persistent storage you may use. This is something that the shown WildDuck API does not appear to support at all, and is in fact something entirely unsupportable on such a style of API. These things are hard to do properly, in a way that will give any semblance of performance or efficiency. (It looks like WildDuck’s web interface does have some way arranged so that changes get pushed to the interface, but that doesn’t appear to be part of its public API, and I can’t imagine that it’s actually a good, flexible and efficient solution. I haven’t looked into how it is implemented at all, however. I’m open to discussion of what I’m confident will be its shortcomings, if you don’t like the aspersions I am casting.) Now to return to papaf’s remark: JMAP’s method batching is not achievable with HTTP/2 or GraphQL; the key difference is backreferences, whereby you can establish data dependencies between method calls, so that you pass part of one method call as an argument to subsequent method calls. To pick a common example of something that the FastMail web interface does, this allows you to express in one HTTP request the following: “find the first ten emails in Inbox, collapsing threads (so that you get one message from each thread only); then, given those, get the threads that they are in; then, given those threads, get the basic details of the emails that are contained in those threads.” In the absence of backreferences, you would need probably three round trips, or a special case in the API that limits flexibility. I will add that JMAP can be usefully combined with HTTP/2 so that you can issue multiple batches of requests simultaneously and use the results as they return. Please read through all the content on the front page of https://jmap.io/ https://jmap.io/. It provides good justification for why quite a few things are how they are. Remember this most important fact: JMAP is an object synchronisation protocol.

Aeolun 7y ago
Would it be best to wait to write a JMAP server until the spec is finalized? Or should I consider the current one mostly final? I’ve had one look at it and while the protocol looks really good, it also looks like I’d rather not implement it more than once ;)
- chrismorgan 7y ago
  The spec is currently in the editor’s queue for publication. I believe that means that no further changes are anticipated.