[Dovecot] v3.0 architecture

[Timo Sirainen]

On Jun 2, 2009, at 11:39 AM, pod wrote:

> Timo Sirainen <tss at iki.fi> writes:
>
>> The big problem is what the protocol should be. Use some existing RPC
>> protocol? It should be something extensible so that a plugin in imap
>> process can talk to a plugin in storage process, without the base
>> processes knowing anything about the details (e.g. imap-quota plugin
>> asking quota usage from storage's quota plugin). In any case the   
>> client
>> side API should be asynchronous. That can make it annoyingly   
>> difficult to
>> use though. Wonder if I could switch to erlang or  something for the
>> imap/pop3 processes :)
>
> I realise I'm coming a little late to this conversation.  Various  
> people
> have suggested various RPC mechanisms.  Might I humbly suggest also
> looking at 9P (or 9P2000) the Plan9 filesystem protocol. [1]
>
> The general design philosophy in Plan9 is not to use an increasing  
> number
> of application specific RPC mechanisms but instead to implement  
> everything
> in a synthetic filesystem tree.

I do kind of like that idea, but I don't really se how it would be  
practical here, especially if high performance is wanted.

1. I'm not implementing Dovecot to Plan9, so the "filesystem" would  
still have to be wrapped in some kind of a protocol. I suppose you  
could get them visible to filesystem using FUSE, but that would still  
be Linux-only.

2. Latency over network is pretty high, so a nice clean filesystem  
layout wouldn't probably be possible without sacrificing performance.  
And a non-clean layout probably would just make it horrible to use in  
all ways.

Actually I think even the current lib-storage API won't be low-enough  
latency. Most IMAP commands should be able to be done by sending a  
single request and then reading responses. Well, I'm not going to  
start coding this anytime soon.

Anyway, I'm still more concerned about how to implement the client  
side so that a single process can asynchronously process commands and  
handle multiple connections, without the code looking awful difficult  
to understand mess. I think it might be possible with C, but I'm not  
aware of any existing code that does it as cleanly as synchronous code  
looks like.