4 ms·

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

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

by dvdhnt 7y ago

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.