Hi Michael, > I am not sure if this kind of proxy (not having all data available locally, > just working with an IMAP backend) was an intended use case when designing > the spec, but it certainly seems *very close* to feasible, save for some > things that seem difficult to me. The spec is designed to allow a consistent JMAP and IMAP interface to the same data, but not constrained to acting as a proxy on top of IMAP (the feasibility of which depends hugely on which IMAP extensions the server supports). You can probably write something that's technically spec compliant (e.g. return cannotCalculateChanges error for every call to /changes), but it's probably not going to be very efficient without some custom IMAP extensions. > - When only doing IMAP-passthrough, it does not seem feasable to offer the > /changes > endpoint at all. However, it is possible to offer /queryChanges within a > single inbox > filter. Does that sound about right? Most IMAP operations operate only on a single mailbox, whereas /changes is across an account. So yes, this is unlikely to be feasible to do sanely using just IMAP operations. With a simple (but common) filter of just `inMailbox: Foo`, implementing /queryChanges should be feasible (as long as the server supports at CONDSTORE/QRESYNC). > I am thinking a client which throws away *all* cached emails when /changes > fails would be missing out on the ability to get the /queryChanges on a > per-mailbox basis. But how the client know that? Because most of the message data is immutable, if /changes fails the client only actually has to refetch keywords/mailboxes. Having said that, it's still not great from an efficiency standpoint. > - In `Mailbox/get` or `Mailbox/query` method, since I cannot really return a > mailbox state … But there isn't really a way for the server to tell the > client: "I don't do changes, there is no stable state value". No, because we want this to be mandatory in a compliant JMAP implementation. A server without this is going to be way less efficient for clients, and part of the JMAP idea is guaranteeing a much higher baseline clients can rely on (a server can say it supports "IMAP", but only support RFC3501 with zero extensions, which is practically useless). > - Implementing threads is though. If you don't have server support, you probably can't do this properly. You could return every message as its own "thread", which would be technically spec compliant but not very useful. Basically, without being able to guarantee a lot of help from the IMAP server (e.g. RFC8474 so you can get proper ids for your mailboxes/threads/emails) it's going to be very hard to write a generically useful proxy while remaining stateless. So it depends what your goals for the project are really; if it's just learn more about IMAP and JMAP, then great! This will probably be a very interesting exercise. But if it's for real world use I think it might be worth constraining the problem somewhat first. Neil.
-- You received this message because you are subscribed to the Google Groups "JMAP" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jmap-discuss/4c37d79a-acbc-4a55-8122-783b416374b9%40sloti7d1t02. For more options, visit https://groups.google.com/d/optout.
