> On 08 Feb 2016, at 13:28, Nagy, Attila <[email protected]> wrote: > > On 02/08/16 12:07, Timo Sirainen wrote: >> On 08 Feb 2016, at 12:56, Nagy, Attila <[email protected]> wrote: >>> On 02/08/16 11:16, Timo Sirainen wrote: >>>> Oh, you were thinking about ability to provide IMAP/etc support for other >>>> random servers, and have Dovecot act as kind of a middleware and translate >>>> the requests. Maybe the answer is still jmap though? It would require jmap >>>> lib-storage backend similar to imapc, which would be doable, although not >>>> really something we're right now planning to implement. >>>> >>> Yeah, the opposite, in this case a jmap backend to Dovecot. >>> BTW, I think jmap is too high level and implementing a jmap server is very >>> much like implementing an IMAP one. >>> >>> I much more think of a pluggable, easy (remote) storage API, which has much >>> less to do with IMAP, but can offer capabilities, which can help Dovecot >>> (like the search and indexes). >> What kind of use cases are you thinking for this remote storage API? What >> kind of remote storages would implement it, and what kind of installations >> would use them? >> > Interfacing non-email systems to e-mail protocols and implementing other > storage options (I can't say a better analogue than what FUSE is). > Using Dovecot as a protocol implementation, but not for the underlying > storage method, which may be custom to the given solution. > A flexible way of implementing and adapting anything to IMAP. > > For example if I want to store really old and archived e-mails in a costly > compression format somewhere in the cloud, but hot mails locally, based on my > custom policies. > In an international company there may be some regulations about what should > go where, so for example if I can handle object placement myself, I can use > the same installation to store non-EU mails in non-EU countries and others in > US or EU clouds if law permits.
You could already implement these with mail-filter plugin. The locally stored mail would be just an object pointer, which the mail-filter plugin reads from the remote storage. Although I think mail-filter is lacking error handling right now. > Intermixing several systems into one (like merging two IMAP accounts into > one) etc. If I bothered to implement per-namespace imapc-settings, this could be done with virtual plugin. > Some of these are very costly to develop in Dovecot, while just a few lines > in -say- Python or go. I think it might not be that easy. Although I've made lib-storage backends easier and easier to implement, it's still not exactly trivial. Implementing it behind some API could simplify it somewhat, but it wouldn't really remove all the difficult work that needs to be done. For example some backends might want to be read-only, others read-write. Some might want Dovecot to store all the message flags and other metadata locally, while others might want to store it themselves (and that would require two-way syncing between them). Some backends would support searching, fetching some headers fast and in general support different kinds of optimizations, while others wouldn't. The imapc backend is of course already implementing a lot of this functionality, but it's also getting complex. The backend would also have to guarantee some things to be compatible with IMAP, mainly never modifying existing mails. One alternative might be to add scripting support to Dovecot. I've been thinking about that several times over the years. So instead of implementing plugins with C, you could implement them with Python or some other language. Long time ago I tried to do this with SWIG, but it didn't work out. The main problem was function pointers in structs, but nowadays those aren't directly called and I think it could be implemented a bit differently.
