On Jun 2, 2009, at 11:39 AM, pod wrote:
Timo Sirainen <t...@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.
