Live data from Hacker News

JMAP: Like IMAP but Not Really

unencumberedbyfacts.com

81–90 of 235 posts

Re: JMAP: Like IMAP but Not Really

#81
post #67

>JMAP is a REST API so it uses HTTP requests and responses to issue commands and get the results. Almost all requests in JMAP are to the same URL using an HTTP POST to submit a JSON body of “methods”. Describing this as REST is really strange. Defining your own operations over an HTTP POST is what SOAP and other RPC style web services do and specifically what REST isn't. But I guess that a lack of a standard behind R…

At this point I guess any API that runs on top of HTTP is REST? Strange world.

I guess REST became catch phrase for all JSON over HTTP protocols.

Re: JMAP: Like IMAP but Not Really

#82
post #4

The article mentions that JMAP does calendars as well. Anyone have a quick status update on how it compares to CalDav and if it's supported by any of the major calendar clients or servers? I did a quick google and looked at the JMAP site but couldn't find any info. Background for this is that I implemented a calendar client and a calendar server (with SabreDAV) last year and I'm wondering if I should be adding suppor…

Editor of the JMAP specs here. The JMAP calendar spec is currently just a draft, but now JMAP core and mail are (more or less) finalised and JSCalendar ( https://tools.ietf.org/html/draft-ietf-calext-jscalendar-11 ) is in last call too, we will be looking to take the JMAP Calendar spec through the IETF process in the very near future. Since it is essentially just combing core with the JSCalendar data format, this sho…

I see, thank you so much for providing inside information. Looks like it'll be a while before I can ditch CalDav...

Re: JMAP: Like IMAP but Not Really

#83

FastMail is behind this protocol and from what I've read JMAP has evolved out of their web interface. I've been a happy customer, even though lately I flirted with going back to GSuite for my personal email, but after a trial realized that Gmail does many things well, except for being a good email service. So I went back to FastMail and renewed for another 2 years. Seeing this new protocol is exciting, because JMAP i…

> after a trial realized that Gmail does many things well, except for being a good email service. This. I remember back when Gmail was new and hot. It was unlike any other email service out there, and ridiculing people for using inferior email-solutions could to a certain extent be justified. While other webmails were slow, had constantly reloading pages and what not, Gmail was fast . It was amazingly fast. Gone wher…

Does FastMail let you have complex conditions in filters though? One huge value of Gmail for me is that I can have arbitrarily complex nested conditions to filter mail using a formula. I've been looking for even more flexible filtering (e.g. custom scripts) and yet I have not even come across anything on par with it.

Re: JMAP: Like IMAP but Not Really

#84
post #12

The main failure in mail standards is a lack of explicit utf8 clean support lhs@rhs -if this got fixed (it's often called universal acceptance) a lot of things about mail as an ecology would improve. I have view on the spam thing. The whole "your idea will not work because" meme is hugely destructive of innovation in email. It sucks energy and mindshare. It's classic old timer put down. What would (imnsho opinion) ha…

> What would (imnsho opinion) have fixed spam is sender pays. I've debated this with a lot of people. We're 50/50 on it. Fifty agree with me, fifty million don't.

I propose a scheme where the sender pays e.g. 5 ct per e-mail (low enough that it does not matter for legitimate use, but high enough to make spam unprofitable). BUT with the following twist: The receiver can generate API tokens that allow free e-mail delivery.

So when I sign up for e.g. Twitter, I can give them an API token for my mail address so they can send notification mails to me for free. If they decide to start spamming me, or if they decide to sell my token to a spammer, I can just revoke the token and the spam flood stops instantly.

I have not found any flaws in this idea yet. RFC!

Re: JMAP: Like IMAP but Not Really

#85
post #12

The main failure in mail standards is a lack of explicit utf8 clean support lhs@rhs -if this got fixed (it's often called universal acceptance) a lot of things about mail as an ecology would improve. I have view on the spam thing. The whole "your idea will not work because" meme is hugely destructive of innovation in email. It sucks energy and mindshare. It's classic old timer put down. What would (imnsho opinion) ha…

Sender pays to stuff junk in my physical mailbox and I have a lot more trouble with spam there than I do in my email.

Re: JMAP: Like IMAP but Not Really

#86

Earlier quoted context omitted.

> after a trial realized that Gmail does many things well, except for being a good email service. This. I remember back when Gmail was new and hot. It was unlike any other email service out there, and ridiculing people for using inferior email-solutions could to a certain extent be justified. While other webmails were slow, had constantly reloading pages and what not, Gmail was fast . It was amazingly fast. Gone wher…

Does FastMail let you have complex conditions in filters though? One huge value of Gmail for me is that I can have arbitrarily complex nested conditions to filter mail using a formula. I've been looking for even more flexible filtering (e.g. custom scripts) and yet I have not even come across anything on par with it.

fastmail lets you write complete scripts for filtering using the Sieve programming language. https://www.fastmail.com/help/technical/sieve.html

Re: JMAP: Like IMAP but Not Really

#87

From experience, Exchange's Outlook API ("EWS") is pretty decent. It's XML-SOAP, sure, but there are libraries for it that can be readily used. The only thing they did fuck up is the three different kinds of IDs for an object (esp. confusing when accessing delegated team mailboxes/calendar events) but once you get it how it works, it's straightforward and allows you access to anything from email over calendar to addr…

I've sadly been looking for, and never found, an open source EWS IMAP/(Cal/Card Dav) gateway. I'd love it if my users could get a full experience using Outlook for Mac for example. Right now I recommend them to just use Apple Mail/Calendar/Contacts or Thunderbird with the tb-sync extensions.

It sounds like you’re describing DAVMail

Re: JMAP: Like IMAP but Not Really

#88

> 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…

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.

Re: JMAP: Like IMAP but Not Really

#89
post #86

Earlier quoted context omitted.

Does FastMail let you have complex conditions in filters though? One huge value of Gmail for me is that I can have arbitrarily complex nested conditions to filter mail using a formula. I've been looking for even more flexible filtering (e.g. custom scripts) and yet I have not even come across anything on par with it.

fastmail lets you write complete scripts for filtering using the Sieve programming language. https://www.fastmail.com/help/technical/sieve.html

Holy cow, I will have to look into this. Thanks a ton!!

Re: JMAP: Like IMAP but Not Really

#90
post #67

>JMAP is a REST API so it uses HTTP requests and responses to issue commands and get the results. Almost all requests in JMAP are to the same URL using an HTTP POST to submit a JSON body of “methods”. Describing this as REST is really strange. Defining your own operations over an HTTP POST is what SOAP and other RPC style web services do and specifically what REST isn't. But I guess that a lack of a standard behind R…

Maybe unpopular opinion, but i'd take this any day over a "proper" REST api requiring DELETE and PUT. Also i'd classify a REST api as anything that does http requests and consumes proper JSON. As long as this is true , the rest is squabbling :)

> i'd take this any day over a "proper" REST api requiring DELETE and PUT.

REST doesn't need to use any HTTP verbs other than GET and POST.

Post reply on HN