At least part of the reason I am advocating a separate headers table is
that I don't see how the header flag would work. I am guessing that you
are suggesting adding a flag to the message_blks table that says this
row has headers in it that is fine but under the current design, a
Jesse Norell [EMAIL PROTECTED] said:
At least part of the reason I am advocating a separate headers table is
that I don't see how the header flag would work. I am guessing that you
are suggesting adding a flag to the message_blks table that says this
row has headers in it that is
At least part of the reason I am advocating a separate headers table is
that I don't see how the header flag would work. I am guessing that you
are suggesting adding a flag to the message_blks table that says this
row has headers in it that is fine but under the current design, a
Seems terribly complicated, and it would make the messages very difficult to
dump by hand. I'm also not sure why you want to have two tables; is that what
you're proposing:
header_labels (index on label)
id label
--
1 to
2 from
3 subject
message_headers (index on
Surely for webmail applications, etc you're after a join where you get the
headers as columns for displaying a message list; to avoid having nested
queries.
E.g. avoid select * from messages; then for each message select * from
headers where messageid=X
I know the goal is to have the headers
I'm thinking in terms of searches primarily, where a query might be:
select distinct(message_id) from fastheaders
where header = 'to' and contents like '%bob%'
You're looking for displaying the message, where the webmail application
probably doesn't want to read in the header blocks of the
Haai,
This is a major problem with most 'redundant' database based systems as far
as i understand it ... When i looked as sql relay it didnt seem to do
anything natively with the database. And considering i havent used it much i
wouldnt be able to yay or nay it. The stuff in the white papers
Oops. Sorry guys... its early here and i havent had my morning coffee :(
P
- Original Message -
From: Patrick [EMAIL PROTECTED]
To: DBMAIL Developers Mailinglist dbmail-dev@dbmail.org
Sent: Thursday, March 18, 2004 8:58 AM
Subject: Re: [Dbmail-dev] Cached Headers (was NNTP)
| Haai,
|
|
Haai,
This is a major problem with most 'redundant' database based systems as far
as i understand it ... When i looked as sql relay it didnt seem to do
anything natively with the database. And considering i havent used it much i
wouldnt be able to yay or nay it. The stuff in the white papers
Well,
I beleive a flag on the messageblock would be a good start, since
it is not that intrusive.
But I am very unsusre about how much performance we would gain by
searching directly in heavily optimized fast-header tables. Is
the pain worth the gain?
Small installations do not need the extra
I like the Linux kernel coding style. To me, it's much more readable
than GNU style, but that's just a matter of familiarity I guess.
Does anybody have objections if I run indent -i8 -kr on the code now,
and release RC4 after that?
Ilja
Aaron Stone wrote:
I'm a fan of GNU style, with two
I might have some objections, but not any particularly valid ones :D Hmm...
think I'll run indent -i8 -kr on some of the code I've been working on and see
what it looks like.. hmm.
Hmm.. I wonder if that'll make things a lot more difficult to merge into our
private cvs copy of dbmail...
Hi,
the INSTALL files says nothing about exim4 (maybe it's to simple?):
LOCAL_DELIVERY=transport_dbmail
Every router with local mail has to use 'transport = LOCAL_DELIVERY'
then.
Two possible transports:
# transport using pipe
transport_dbmail:
driver = pipe
command =
Hi all,
We've found a small error in insert_message_temp() in pipe.c.
The buffers strblock and tmpline were not initialised with '\0'
characters. Because of this, sending emails with an empty body resulted
in the message body possibly being filled with random characters (or
worse, characters
The sizes returned through the msgsize, rfcsize, headerrfcsize, etc. variables
should all have been zero. So there's also a problem of assuming a non-binary,
null terminated message. Aren't now email programs encouraged to support
binary data nowadays?
Aaron
Ilja Booij [EMAIL PROTECTED] said:
Well,
I like your idea, but why not fill the title table automagically
as you find new headers? Then you don't need the title_id 3 in
your example.
But I am still not sure how much the performance gain is by
putting it into separate tables compared to searching on the
message blocks.
Hi,
I'd like to release rc4 tomorrow. Is anybody aware of any showstoppers
we have to fix before releasing rc4 other than the ones I'll mention below?
* Headers 512kB don't work. Messages get dropped.
* code indentation: run indent -i8 -kr (unless anybody wants something
completely
But I am still not sure how much the performance gain is by
putting it into separate tables compared to searching on the
message blocks.
Consider a hypothetical user who passes 2-5MB documents back and
forth between colleagues all day long, and for whatever reason (he
is part of
null terminated message. Aren't now email programs encouraged to support
binary data nowadays?
I would guess so. rfc 2822 is much less restrictive on valid character
set in a message than 822. Eg. 822 did not allow NULL's in email, but
2822 does. dbmail is 822 compatible in that reguard,
If I understand everything correct, the headers goes into the
first messageblock and the rest of the message goes into the next
message blocks.
With a flag on the message block containing marking it as a
header block will we only search the header blocks and these are
usually not that
But I am still not sure how much the performance gain is by
putting it into separate tables compared to searching on the
message blocks.
Consider a hypothetical user who passes 2-5MB documents back and
forth between colleagues all day long, and for whatever reason (he
is part of
For the uber-large headers problem, would you rather bounce the message or add
the is_header column to the messageblks table and allow for multiple header
blocks? Also, since we currently pass the header around as a single char
array, how would you propose to throttle the memory usage so that
A flag on the messageblks field would certainly help, and allow webmail
applications to generate message lists with one query
E.g.select messages.*, messageblks.messageblk as headers from
messages,messageblks where
messages.message_idnr=messageblks.messageblks_idnr and
messageblks.isheader=1
Having a flag on the messageblks is great for joins (see previous post); but
if there is the possibility of multiple header blocks that may pose a
problem.
However -- you could set the value to 1 for 1 header block, 2 for
multiple header blocks (or qty, etc) -- and then if when you do the simple
This query will get you the headers and the flags of each message in a give
mailbox. A strictly ascending messageblk_idnr column is assumed.
select messages.*, min(messageblk_idnr), messageblk from messages,
physmessage, messageblks where messages.physmessage_id = physmessage.id =
25 matches
Mail list logo
