On 02/08/16 12:07, Timo Sirainen wrote:
On 08 Feb 2016, at 12:56, Nagy, Attila <b...@fsn.hu> 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.
Intermixing several systems into one (like merging two IMAP accounts
into one) etc.
Some of these are very costly to develop in Dovecot, while just a few
lines in -say- Python or go.
