Did something happen to the comments? I'm seeing 78 upvotes and no comments.
Fastmail uses Hacker News to spam, I mean publish all their new developments.
JMAP – a better way to email
91–100 of 116 posts
Re: JMAP – a better way to email
#92Earlier quoted context omitted.
Less than pleasant first experience. Card failed, reason never communicated clearly enough. Very slow and archaic support.
Archaic?
Fax documents and payment information, poorly formatted support replies, supervisor escalation system after a couple different people over 2 weeks couldn't address a simple on-boarding issue.
Re: JMAP – a better way to email
#93Did something happen to the comments? I'm seeing 78 upvotes and no comments.
Fastmail uses Hacker News to spam, I mean publish all their new developments.
In general I dislike FastMail promotion on HN.
But this article is different - it's some new open development, potentially very useful to many users, and its success is directly related to the number of developers who will pick it up. So at least this time it deserves some attention.
Re: JMAP – a better way to email
#94I hate to be critical considering the considerable work they've put in, but I don't buy their "JMAP is actually more REST-like than most “RESTful” APIs" statement. But maybe I'm missing a whole lot. REST doesn't preclude doing multiple things in one round trip. Well it does seem JMAP is a bit more flexible when it comes to multiplexing very different actions. But the error handling doesn't seem to tell you which comm…
Each call is tagged by the client and the same tag is added to the response by the server, so you can tell exactly what error corresponds to which call. Caching is pretty easy: you just keep a cache of each object type. The delta update mechanism means you can very accurately invalidate what you need to keep it up to date. The system is actually really flexible and a great fit for any CRUD based app; JMAP is really j…
Oh right, now I see the:
["error", { type: "unknownMethod"}, "client-id"]
-bit. Still, it sounds like you're reinventing HTTP verbs and statuscodes and embedding them inline in the JSON just to be able to multiplex the calls. Might as well use HTTP2 or SPDY, then.
Also, caching JMAP may be easy on the client side, but not for any intermediate cache - unless it understands JMAP.
I'm not saying RPC over HTTP is bad, mind, but you do seem to lose some of the benefits of HTTP.
Re: JMAP – a better way to email
#95Earlier quoted context omitted.
Each call is tagged by the client and the same tag is added to the response by the server, so you can tell exactly what error corresponds to which call. Caching is pretty easy: you just keep a cache of each object type. The delta update mechanism means you can very accurately invalidate what you need to keep it up to date. The system is actually really flexible and a great fit for any CRUD based app; JMAP is really j…
Not just some objects, but different methods to access different objects, and it's those methods that implement the semantics - the base of JMAP is just an encoding for bulk RPC. What I mean is, if tomorrow I add a file with the mediatype application/vnd.icebraining to my server, an intermediate HTTP proxy can still cache it even though it knows nothing about my format. But if I add a new object (say, Note) to my JMA…
While I agree with you that in general there's nothing wrong with RPC, I'm not sure what the advantage in this case is. You seem to have an idea, though…?
Re: JMAP – a better way to email
#96Earlier quoted context omitted.
Plain text passwords. No amount of blablabla can excuse that. Plain text passwords.
So all those services you use right now where you type in a password. How exactly are those passwords transmitted to the server?
The plaintext password could probably be replaced by hashed passwords. Directly within the spec. Even though it already allows additional or different layers of security, this motivates developers to implement a basic level of security right into the application layer.
Re: JMAP – a better way to email
#97I understand you guys use and contribute to Cyrus. Is there a JMAP interface planned for Cyrus? Or for any other mail servers, like Dovecot?
from the article itself: "Finally, we know IMAP, SMTP and the DAVs aren’t going away any time soon. No protocol will succeed unless it provides an upgrade path from where we are now, and a compelling reason to switch. We will provide a proxy which can talk to existing servers and present them over JMAP."
Your comment implies that the quote you provided answered my question. It didn't.
Re: JMAP – a better way to email
#98Earlier quoted context omitted.
Not just some objects, but different methods to access different objects, and it's those methods that implement the semantics - the base of JMAP is just an encoding for bulk RPC. What I mean is, if tomorrow I add a file with the mediatype application/vnd.icebraining to my server, an intermediate HTTP proxy can still cache it even though it knows nothing about my format. But if I add a new object (say, Note) to my JMA…
While I agree with you that in general there's nothing wrong with RPC, I'm not sure what the advantage in this case is. You seem to have an idea, though…?
Oh, you'd have to ask the JMAP devs. But I do think they'd have to bend the constraints pretty hard to have a RESTful interface while keeping the same advantages w.r.t. efficiency in the number of requests and data transferred.
Like Fielding writes in his dissertation, "The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction."
Re: JMAP – a better way to email
#99I understand you guys use and contribute to Cyrus. Is there a JMAP interface planned for Cyrus? Or for any other mail servers, like Dovecot?
http://git.cyrusimap.org/cyrus-imapd/tree/imap/http_jmap.c?h...
Totally a stub right now, but yes - we would like to have it directly in Cyrus...
Re: JMAP – a better way to email
#100Earlier quoted context omitted.
So all those services you use right now where you type in a password. How exactly are those passwords transmitted to the server?
The plaintext password could probably be replaced by hashed passwords. Directly within the spec. Even though it already allows additional or different layers of security, this motivates developers to implement a basic level of security right into the application layer.
What prevents an attacker from using the hashed password (without decoding it) in his/her own requests?