Hi All, especially Aaron,
I have trouble compiling the code with the a8 patch. Mainly because I
cant seem to get libSieve to compile.. But also because it's, for now,
impossible to compile without the libSieve headers. The new Makefile.am
does not really solve this problem, because it does not work..
* It uses subdirectories for storing the sorting code. Which files
should go in to those directories?
* It uses @SORTALIB@ and @AUTHALIB@, but they are not mentioned
anywhere in the other autotools files. Should there be something
included in acinclude.m4?
Aaron, could you correct this (or am I doing something extremely
stupid?)
Ilja
On Dec 22, 2003, at 10:26 AM, Aaron Stone wrote:
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
--
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
--
IC&S
Stadhouderslaan 57
3583 JD Utrecht
telnr. 030-6355730
faxnr. 030-6355731
PGP-key:
http://www.ic-s.nl/keys/ilja.txt
