5 ms·

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

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

dvdhnt 7y ago
This isn't on topic of GP, but you seem to have a handle on what this is, so I thought I'd ask... 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. source: https://news.ycombinator.com/item?id=20478227 https://news.ycombinator.com/item?id=20478227
- e12e 7y ago
  Note that you can retrieve arbitrary files over IMAP too - there's not that much "email" about it. And as one quickly realize: it makes sense to solve the general problem first (implement a document database, essentially) and then add "special sauce" for email (eg: a notion of sender/receivers, threads etc). 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/ http://dbmail.org/
- theOnliest 7y ago
  (I also work at Fastmail, on the server side.) 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 https://github.com/fastmail/Ix. Ix is the basis for Topicbox (www.topicbox.com), which is built ground-up on top of JMAP.

dvdhnt 7y ago

This isn't on topic of GP, but you seem to have a handle on what this is, so I thought I'd ask... 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. source: https://news.ycombinator.com/item?id=20478227 https://news.ycombinator.com/item?id=20478227

e12e 7y ago
Note that you can retrieve arbitrary files over IMAP too - there's not that much "email" about it. And as one quickly realize: it makes sense to solve the general problem first (implement a document database, essentially) and then add "special sauce" for email (eg: a notion of sender/receivers, threads etc). 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/ http://dbmail.org/
theOnliest 7y ago
(I also work at Fastmail, on the server side.) 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 https://github.com/fastmail/Ix. Ix is the basis for Topicbox (www.topicbox.com), which is built ground-up on top of JMAP.