![]() well-known, so that you can just provide an email address and it’ll figure out the rest) instead of two with no consistently applied configuration procedure is a surprisingly big deal for users. And having only one thing to configure and get right, with a standard configuration procedure (SRV and. Even things like synchronisation and notifications come at very low cost even without a library, especially if you are running in a web browser.ĭon’t forget that JMAP replaces IMAP and SMTP for the MUA. ![]() Because it speaks HTTP and JSON and is deliberately designed as a synchronisation protocol, and because it lacks the cruft of decades of fragmented extension that IMAP has¹, JMAP is really easy to work with. JMAP allows you to get started quickly and efficiently. Sure, you’ll probably want to introduce offline support and may want to reimplement search on the client somewhere down the track, but it’s not necessary-work-that-must-be-done-before-the-client-is-generally-useful like it is in IMAP. JMAP, on the other hand, is designed to work in such a situation, and suffers from few of those sorts of shortcomings. We couldn’t make something like the FastMail web UI speaking IMAP it just wouldn’t work in too many places. You can do it, and many clients have over the years, but you will sacrifice a lot, like the ability to search multiple folders efficiently. IMAP is not particularly well suited to being used as a purely-online client with no local storage or persistent cache. They’ll be other things altogether that just happen be able to send or receive emails directly, now, because it’s finally easy enough to. Some of the experiments that I’m looking forward to seeing won’t look like existing MUAs at all. But for authors of new MUAs and other programs that might want to do email at all-sending or receiving-JMAP really is “all that”. You can send messages without having to implement SMTP and grok MIME, too.įor authors of existing MUAs, JMAP doesn’t have much to offer by this stuff from the last paragraph-they’ve already done the hard slog. ![]() as lists of addresses and fields like preview, htmlBody, textBody and attachedFiles to save you the trouble of deriving the crazy convoluted rules of multipart messages. is answered by no library that I know of.) JMAP doesn’t solve all these problems, but it handles most of them by handing you a sanely parsed message (putting the burden of sanity on the server, and the spec provides good guidance and there’s a JMAP test suite being made to ensure the sanity of the server): things like exposing To, Cc, &c. (You’ll find some that do the plain parsing of most of the message, but how do I decide what to do with multipart/alternative, multipart/mixed, text/plain, Content-Disposition, Content-Encoding, &c. IMAP is also only one part of the app: one of the hardest parts is MIME, and figuring out what to show for an email and how to craft an email there are fewer libraries to do this than there are IMAP clients-and almost none that are any good. Bugs in clients or servers that cause data loss over IMAP are not unheard of. There are many extensions for many features, poorly supported in various clients and servers, and various things that are slow, difficult, or impossible to do in IMAP that JMAP can express elegantly. IMAP is a mess if you try to do much beyond the basic “retrieve list of folders, retrieve messages, now just leave it alone” and most IMAP client libraries are worse than IMAP need be. I perceive that you haven’t ever tried programming against IMAP or making a MUA, or not seriously at least.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |