Re: bincdrop - a (courier) maildrop replacment

Peter Stuge wrote:
> On Mon, Jul 25, 2005 at 02:08:18PM +0200, Jerry Lundström wrote:
>>
>>I can't really see a better solution then plain files since dbm
>>files will break distributed filesystems.
> 
> dbm as in dbase or in database management? And why does contents
> matter.. Oh, you mean one single database for all users - yes, I
> see.. Well, that rules out some backends, but not all. A central SQL
> server could do the job and serve all bincimapds.
> 
> Let me clarify; I don't have any more problems with the way things
> work right now - a couple of extra files in the maildir - they sort
> of bother me, but the performance gain alone is motivation enough.
> 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.

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, meaning that you give it a filepath and what happens in 
the backend isnt for you to know but you get a stream or something like 
that back. That would be neat to have for every kind of data and will 
enable ppl to build mailsystems that doesnt need some kind of advanced 
network filesystem since it can just talk to a mysql cluster.

>>But this doesnt stop bincdrop and I would really want to see
>>bincdrop included inside bincimapd because it's easier to reuse and
>>maintain the depot and mime code that bincdrop will use.
> 
> I'm all for bincdrop using the same codebase that bincimapd does, and
> I don't mind bincdrop being included in the bincimap package, but I
> can imagine other uses for bincdrop at times when one doesn't want
> bincimap, so it would be a good idea to package bincdrop on it's own
> as well. And then it may not be a good idea to have it included in
> bincimap anymore. :) But I absolutely agree it should reuse binc
> code, that's still possible, right?

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

> ..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.

-- 
Jerry Lundström
Sektionen för IT och media, Stockholms universitet
+46 (0)8 16 19 99 / http://www.it.su.se