Re: bincdrop - a (courier) maildrop replacment

On Mon, Jul 25, 2005 at 02:08:18PM +0200, Jerry Lundström wrote:
> Peter Stuge wrote:
> >Sure, MIME will work, except that it's hard to work with for
> >everyone else, who don't have a nice MIME parser at hand. :)
> 
> And for ppl that want to edit it by hand.

True as well.


[..]

> >Sorry, I should have been more clear. I didn't mean for storing
> >mail but for storing binc's internal metadata, to get rid of
> >.binc* files.
> 
> 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.


On Mon, Jul 25, 2005 at 02:08:47PM +0200, Jerry Lundström wrote:
> Peter Stuge wrote:
> >On Mon, Jul 25, 2005 at 08:58:57AM +0200, Jerry Lundström wrote:
> >
> >>So the changes would be adding bincdrop into the bincimapd suit and
> >>adding the extention of managing the scripts.
> >
> >Add bincdrop to bincimap suite or even package separately. I'd prefer
> >the latter actually since both could be used without each other. But
> >as far as I can tell, MANAGESIEVE isn't an IMAP extension. I would
> >like it a whole lot more if it was.
> 
> Gah, you are so right, I got blinded by the sieve code in
> cyrus-imapd/imap/ that I didn't see the timsieved. And its Tim
> Martin that has written the draft and make the daemon. Well that
> isn't an option.

Yes and no.. I agree it's a bad idea to add a managesieve daemon to
binc, but the problem still needs to be solved. Users' scripts have
to be accessible somehow, and the easier (for both man and machine)
the better.


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

..perhaps break out lowlevel shared things into libbinc? Am I getting
carried away? :)


//Peter