I´m not sure if i´m being quite clear about my solution (pardon my english)...
I´m not thinking in any filesystem abstraction layer, I´m afraid of this kind of solution. If some corruption happens we can loose data - and the crash-recovery is not easy.
I´m suggesting the opposite, to not have an abstraction layer. The abstraction layer would be the proxy - dovecot does the abstraction layer. When I´m telling 'proxy' I meaning something like the proxy feature of the dovecot.
And in my head the final solution is very 'simple' (despite of its hard programming work). Dovecot just access 'in parallel' a set of servers, requesting their informations (really, with imap connection) and caches them - the results (maybe in some database, as you suggested). It would be an extension of the proxy feature that already exists at dovecot.
Fernando
On Tue, 2009-08-25 at 12:12 -0300, fernando@dfcom.com.br wrote:
Hi Timo,
Yes it´s related, but I don´t understand '... You'll just need to implement a filesystem that allows distributing a single user's mails to multiple servers ...'.
My idea is just in the direction that we don´t need to care about filesystem, we don´t need any distribuited filesystem...let it be as user wants....at any some proxy level, the end storage can be ext3, reiser, S.O linux, freebsd, and so on. I think that the more elements we insert, the more complex and hard to mount/debug the solution would be.
I mean Dovecot accesses filesystem through a simple abstraction layer. You wouldn't have to implement a real OS level filesystem, but you'd implement a "proxying Dovecot-filesystem backend" that sits on top of real filesystems. It's probably not much of a difference to what you're thinking about, except in my mind it's entirely isolated from actual Dovecot code. There's just a simple API that the backend needs to implement and it'll work with Dovecot.
BTW. Maybe http://www.xtreemfs.org/ or http://www.gluster.org/ already does what you're thinking about? I haven't looked at them closely enough..