Cool, glad that insert_messages() abstacts the physmessage stuff. I kinda got that from a quick read, but no time this weekend to read into it that much.
The db_copymsg() changes will be included in a9... although if you'd like, I can send a separate patch to the list if you want to include it sooner. I was actually quite disappointed with the state of the Sieve interface; I thought I had it a lot farther along than it actually is :-\ Anyways, I wrote it for libSieve-2.2.0pre1 and this week I'm going to have pre4 which has a lot of things changed and really a lot of things fixed. For now, just getting the LMTP daemon, the unified delivery layer and the sort/ directories set up should take enough of everyone's time, and are not even affected by the broken Sieve situation -- just don't ./configure --with-sieve. Once the framework is in CVS, I'll focus on the Sieve issues. Aaron Ilja Booij <[EMAIL PROTECTED]> said: > Hi, > On Dec 20, 2003, at 6:33 AM, Aaron Stone wrote: > > > Just following up to my own message here, I went ahead and tried out > > the > > directories thing in my own source tree, and it works like a charm. > > I'm going > > to do some more hacking on the lmtp/sorting/sieve patch set and get > > version a9 > > up onto the SourceForge project this weekend, or maybe Monday > > afternoon. > I'll just start testing with the a8 patch. And when you're finished > with the a9 version (and everything works :) ), we'll use that one. > > > > Oh, Ilja, I noticed that you changed the return type of db_copymsg() > > again. I > > gave you a polite time about it, then later a hard time about it... so > > now > > I'll spare no mercy! db_copymsg() really really must give back the id > > number > > of the new message that it has created! I patched it to add the fourth > > arg: > > > > int db_copymsg(u64_t msg_idnr, u64_t mailbox_to, > > u64_t user_idnr, u64_t *newmsg_idnr); > > > > Lemme know if that works right, or if I have to fiddle with > > physmessage or > > something crazy like that... I'm not sure yet if I understand how to > > use the > > physmessage layer. Uh, actually, I'm just ignoring it and pretending > > that the > > higher level functions like db_insert_message() take care of > > physmessage for > > me. Is that the case or do I need to rewrite to support physmessage > > directly? > You're completely right. I thought I changed it to return the > message_idnr as a call-by-reference parameter. But I didn't.. > > You're correct that functions like db_insert_message() will take care > of the physmessage table. No worries about that. > > Ilja > -- > IC&S > Stadhouderslaan 57 > 3583 JD Utrecht > telnr. 030-6355730 > faxnr. 030-6355731 > > PGP-key: > http://www.ic-s.nl/keys/ilja.txt > > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
