Great!,
1 comment below.
Roel Rozendaal - IC&S wrote:
yeah it is about time we start thinking about it ..
top-issue: shared folders, imap performance
snip
as for the imap-performance:
snip
table structure and program logic. Finally, i would like to create an
abstraction layer such that messages can be linked to multiple
mailboxes. The win here is not so much benefits for the smtp but again
to the imap server as the imap protocol does not have a MOVE command -
when you move a message in your mailclient the mail is now copied then
deleted requiring all the messageblocks to be re-inserted. With this new
layer a COPY would just mean inserting a link-entry occupying just a few
tens of bytes instead of kilo- or even megabytes.
Why not add a hash index of the complete message to the message
table.
This way can we quickly search the message table of the last 100
messages ( with auto_increment id's) in order to find duplicate
message entries. I.e. we will not get the database full by
somebody sending a large attachment (most often word documents)
of several tens of megabytes to the whole company.
This is also good for nightly bookkeeping, shrinking the database
size by eliminating duplicates.
The next question is, this will be a performance hit on the SMTP
receive side and disk is cheep, what is the best solution.
The only reason to add a hash is to improve databse performance.
It might be enough to just add an index to the message binary data.
These are the plans so far, please consider these ideas and give me your
thoughts about it! It would be great to have a plan for dbmail 2.0 by
the end of next week.
regards roel
_________________________
R.A. Rozendaal
IC&S
T: +31 30 2322878
F: +31 30 2322305
www.ic-s.nl
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
regards,
Magnus Sundberg
