Re: DBmail webmail app

>> What about breaking the message up into its
constituent parts
>> (headers, body, attachments, etc), so that
single-instance storage can
>> be achieved?

> I have sometimes wondered about storing (large? say
> n mbytes)
> attachments as files outside the DB. Generally I assume
most of the size
> of a db comes from these attachments and you can't
search them anyway
> (most are probably jpegs/mpeg etc) so keeping them in
the DB seems less
> useful.

Actually, the major benefit was in the first sentence of my
comment - 
*single*-*instance*-*storage*.

By storing the constituent parts of a message in a DB, and
MD5-summing 
them (or whatever algorithm floats your boat), you can very
easily allow 
for single-instance-storage, so that if someone completely
different 
sends or receives a message with funny_picture.jpg (25MB) as
an 
attachment, and this file already exists in the message
store, it is 
simply linked to, not stored...

This capability alone would probably reduce my mailstore by
80+%.

-- 

Best regards,

Charles
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

On Thu, May 31, 2007, Charles Marcus <CMarcusMedia-Brokers.com> said:

>>> What about breaking the message up into its
constituent parts
>>> (headers, body, attachments, etc), so that
single-instance storage can
>>> be achieved?
> 
>> I have sometimes wondered about storing (large? say
> n mbytes)
>> attachments as files outside the DB. Generally I
assume most of the size
>> of a db comes from these attachments and you can't
search them anyway
>> (most are probably jpegs/mpeg etc) so keeping them
in the DB seems less
>> useful.
> 
> Actually, the major benefit was in the first sentence
of my comment - 
> *single*-*instance*-*storage*.
> 
> By storing the constituent parts of a message in a DB,
and MD5-summing 
> them (or whatever algorithm floats your boat), you can
very easily allow 
> for single-instance-storage, so that if someone
completely different 
> sends or receives a message with funny_picture.jpg
(25MB) as an 
> attachment, and this file already exists in the message
store, it is 
> simply linked to, not stored...
> 
> This capability alone would probably reduce my
mailstore by 80+%.

It's on the feature wishlist, but I don't think we can do it
this year.

It really comes down to how long we want to be in
development on the next
release. Clustering, better scalability, and some key new
IMAP features
are probably more important goals, and we can do a stable
release on
mostly the same database schema as we have now. If we try to
do all that
and rip up the database schema all at once, we'll certainly
be in dev
until late 2008.

Many of the proposed features are good targets for sponsored
development.
If there's code that you really want moved to the front of
the priority
list, sponsoring its development can do that!

Aaron
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail