[Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem

[Timo Sirainen]

On Mon, 2009-09-28 at 17:57 +0100, Ed W wrote:
> My only request to Timo was to kind of consider that a bunch of these 
> ideas from the audience will almost certainly involve splitting up the 
> mime message into component parts and that the abstracted interface 
> should try not to throw away any potential speed benefit that this might 
> achieve because the interface can't express what it needs clearly enough?

It might become too complex to initially consider how to support split
MIME messages and such. I'm not really sure if it even belongs to this
filesystem abstraction layer. I was hoping that the FS API would be
really really simple and could also be used for other things than just
email.

But I'm also hoping to support things like single-instance storage at
some point. I'm not really sure if that should just be written into dbox
code directly or try to abstract it out..

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20090928/aa645c02/attachment.bin