Hi everyone, I've been working on a JMAP server that would be a proxy in front of IMAP, but notably, without storing any data locally, like the existing Perl proxy does. The code is here: https://github.com/miracle2k/jmap-python/blob/master/jmap/server/modules/imap.py
It's very much a work in progress, but it can answer basic queries. So far, so good. 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. Here are my question. I would appreciate any time people have to look them over. - 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? 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? - In `Mailbox/get` or `Mailbox/query` method, since I cannot really return a mailbox state (I don't think?), I use the current timestamp. However, we would not want the client to throw away the full local state in this case, right? I mean, the state indicates that whatever is in the cache cannot be trusted. But combined with the fact that there is no ability to query changes, the client will just have to accept that it will have to do poll refreshes whenever it desires. 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". - Implementing threads is though. For collapsing an `Email/query` response, we can use `THREADS`. But there isn't really a good way to answer the `Thread/get` resource, except in the common case where `Threads/get` is executed as part of a multi-method request. That is, it might be feasible to keep the response from `THREADS`, acquired during `Threads/get` in memory for some time to answer any `Thread/get` call the client might issue after that. The common theme here, I think is this: This kind of proxy functions, in effect, as the "online" model defined in RFC 1733. It seems to me that it is entirely possible to map this to an "online JMAP" model, that is, the client sends a request for every view it want to display: - Read the mailboxes on every app start (and occasionally refresh). - Page through the mails in the open folder (with the right IMAP extension, we can even support a limited `queryChanges`). - If a threaded view is desired, use collapseThreads=true while paging. This could be a working client. However, maybe the full JMAP feature set cannot be supported: Maybe Thread/get has to be limited. So, I am not sure. Am I missing something? What would the place for an "online-IMAP" proxy in the JMAP ecosystem be? Would it be forced to remain a non-standardized subset of JMAP that only works with clients that are lucky to not use more than what is provided? Michael -- 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/3431da91-9598-4c5b-a812-53b00d5a8bbb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
