JSON Mail Access Protocol Specification (JMAP)
1–10 of 65 posts
Re: JSON Mail Access Protocol Specification (JMAP)
#2This is similar to what we're using at FastMail for our web interface, but simplified and made a bit more generic based on our experiences over the past year.
Our plan is to port our web interface across to this spec and implement both a direct backed in Cyrus IMAPd and a standalone implementation which can proxy for existing IMAP servers.
Re: JSON Mail Access Protocol Specification (JMAP)
#3HTTP itself has an overhead, I'm skeptical changing a persistent IMAP connection into a request/response model with a different serialization format is going to be more efficient, especially given compression (like COMPRESS=DEFLATE)
IMAP4rev1 is one thing, but there are many extensions supported in modern imap servers to speed up syncing and mailing, like CATENATE/BURL/CONDSTORE/MULTIAPPEND/MOVE/etc
Granted, the IMAP protocol is pretty hairy and difficult to work with. On the other hand, there's a huge ginormous deployment of it on the client and server, and the IETF WG behind it. I doubt JMAP will replace it anytime soon unless the WG itself takes up the issue. And given the neckbeards there ;-), some of whom have been working in IMAP for decades, you face the same opposition to change as those trying to legalize drugs or gay marriage. ;-)
We're still trying to get IPv6 deployed!
Re: JSON Mail Access Protocol Specification (JMAP)
#4As a complete aside, what is the language used under the section "getMessageList"?
Re: JSON Mail Access Protocol Specification (JMAP)
#5HTTP itself has an overhead, I'm skeptical changing a persistent IMAP connection into a request/response model with a different serialization format is going to be more efficient, especially given compression (like COMPRESS=DEFLATE) IMAP4rev1 is one thing, but there are many extensions supported in modern imap servers to speed up syncing and mailing, like CATENATE/BURL/CONDSTORE/MULTIAPPEND/MOVE/etc Granted, the IMAP…
That's why a major focus of JMAP is to be able to be put in front of an IMAP server with a proxy (and it takes advantage of CONDSTORE if present - we built from an IMAP base)
Honestly, if it's not significantly nicer to work with than IMAP, it won't see traction, and that's fine.
Mind you - MOVE took bloody long enough in IMAP, I was arguing for it for years before it finally got support behind it. There's still not much support for SUBMIT via IMAP though, which means multiple connections via different protocols to do basic emailing, with all the support fun that entails.
Anyway - worst case, we still have a better protocol for our own stuff, and that's not nothing.
Re: JSON Mail Access Protocol Specification (JMAP)
#6As a complete aside, what is the language used under the section "getMessageList"?
That's just their own pseudocode language
Re: JSON Mail Access Protocol Specification (JMAP)
#7I maintain an imap client library for PHP ( https://github.com/tedivm/Fetch ), which is far more painful than it really should be. I really am happy to see attempts at a more modern approach.
Re: JSON Mail Access Protocol Specification (JMAP)
#8[deleted]
Re: JSON Mail Access Protocol Specification (JMAP)
#9Looks very useful.
Re: JSON Mail Access Protocol Specification (JMAP)
#10HTTP itself has an overhead, I'm skeptical changing a persistent IMAP connection into a request/response model with a different serialization format is going to be more efficient, especially given compression (like COMPRESS=DEFLATE) IMAP4rev1 is one thing, but there are many extensions supported in modern imap servers to speed up syncing and mailing, like CATENATE/BURL/CONDSTORE/MULTIAPPEND/MOVE/etc Granted, the IMAP…
> I doubt JMAP will replace it anytime soon unless the WG itself takes up the issue.
Maybe. I'm curious what the effect would be if a single mobile platform provider (iOS, Android) supported a new protocol with a single main free mail provider. Specifically, Gmail and Android could possibly push major change through.
Look at SPDY, it was originally an experiment with Chrome and only a subset of Google services, and is now being deployed to other properties and iterated on rapidly in other browsers, too.