Re: bincdrop - a (courier) maildrop replacment

On Tue, Jul 26, 2005 at 08:58:02AM +0200, Jerry Lundström wrote:
> Peter Stuge wrote:
> >I'm just saying that if we start adding more than one or two files
> >to the maildir I think it would be nice to have the possibility to
> >switch to another backend for bincimapd's metadata (subscriptions,
> >cache and uidvalidity) as well as bincdrop's filters.
> 
> I only disagree to this because the most common setup of a imapd
> server is to have a distributed/network filesystem (nfs afs samba)
> and there is alot of problems having filebased databases such as
> db, gdbm and sqlite on such filesystems.

Yes, the fs:es don't have locking. But for those who don't have a
separate storage server the DBMS:es you mention work great.


> What I agree about is that implementing a generall storage backend
> (and this is not only for the maildir class) that can store data in
> a directory way,

Mh, I'm not sure I want it to be hierarchical, but ok.

I didn't want to use this for depot abstraction, since that's already
done in binc, it's possible to just write a new depot and have
whatever support desired.

But you have a point, if there's a (simple) metadata storage solution
with classes for a couple of DBMS solutions, it wouldn't be too hard
to make a Depot wrapper around it. :)


> enable ppl to build mailsystems that doesnt need some kind of
> advanced network filesystem since it can just talk to a mysql
> cluster.

Storing mail in a DBMS has been discussed already, and Andreas shot
it down for scalability reasons - there's simply better performance
in a file system. But yes, if there's a clever storage solution in
the background somewhere, the IMAP server will have to know how to
use it to access the depots.


> I think this should be desided by Andreas, either solutions is
> possible, it just a matter of taste really.

Right. What do you think about it, Andreas?


> >..perhaps break out lowlevel shared things into libbinc? Am I
> >getting carried away? :)
> 
> Hehe, yes =) I think it's easier just to distribute the same needed
> code twice.

It uses more RAM and leads to slower deliveries.


//Peter