That may be a problem for folks running things at the proverbial web scale, but if it's just a Dovecot server handling a couple of dozen or hundred accounts, is it that big of an issue?
That may be a problem for folks running things at the proverbial web scale, but if it's just a Dovecot server handling a couple of dozen or hundred accounts, is it that big of an issue?
No, unless you're designing a protocol to replace IMAP and you want all the proverbial web scale systems to adopt your new protocol. And then again, interoperability and universal adoption is probably something the smaller Dovecot installations would want.
Master-master conflict-free eventual consistency systems are easier and safer to operate, there's no nightmare damage from split-brain and things just work, even in the worst scenario. Master-slave failover is notoriously prone to error, even for small deployments.
The conversation seems to focus on JMAP as a replacement for IMAP and primarily as an email protocol. The RFC identifies itself as - > a protocol for clients to efficiently query, > fetch, and modify JSON-based data objects, with support for push > notification of changes and fast resynchronisation and for out-of- > band binary data upload/download.
It reads like it applies to APIs in general, or is this only for mail/messaging services?
edit: I see now, this is the core spec, not specifically the mail spec as referenced in another comment. Thanks.
I've wondered for a while how hard it would be to wrap dbmails[db] (postgres) schema/db in graphql and call it a day, for a jmap work-a-like, for example.
[db] http://dbmail.org/
It does describe APIs in general, and that is one of the reasons I like it so much. All of our internal APIs are JMAP: when you need to do something with a user, you call User/set; with a rule, call Rule/set, and so on.
JMAP makes it super easy to build new APIs because you can reuse most of the code; the only things you need to define are the data types (and any custom implementation for access controls, etc.).
Although Fastmail itself has much more legacy code (we’ve been around a while!), new things can start with a framework called Ix, which is available at https://github.com/fastmail/Ix. Ix is the basis for Topicbox (www.topicbox.com), which is built ground-up on top of JMAP.