RFC: HTTP based storage API

[Nagy, Attila]

On 02/08/16 12:07, Timo Sirainen wrote:
> On 08 Feb 2016, at 12:56, Nagy, Attila <bra at 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.