On Donnerstag, 15. März 2007 11:16 Aaron Stone wrote: > Paul and I write the code that interests us and what we can sell > support contracts for. This feature would be a lot of work for > hack-value equal or less than many of the other features we've got on > the drawing board. If there were a strong business case, that would > definitely change the equation!
Although a bit OT to my question, but the idea of storing attachments on their own sounds very interesting - remove duplicates, which could for most servers save a certain amount of disk space (think about those joke .ppt and .avi going to hundrets of users all the time) - make stats (hown much disk space saved, average attachment size, which types are used more often etc.). I love stats, and managers love stats - you can show them nice graphs how much disk space you saved, and this saves backup space, you don't need new tapes etc. You could adapt the schema without having to change existing e-mail, I would say - they are stored the old way, and only new e-mail would be split up. That way, the admin could make a transition easy with imapsync, or manually by moving e-mails around. I can't really benchmark this, it's a customers server, no time for playing around there. Cyrus works, so I won't touch it. I would have thought that big messages are no problem, as the DB should be much faster than the network anyway. Even when a message has 100MB, that would only be 50x512KB to store in messageblks. And to find and retrieve 50 blocks can't be that hard, especially when there's an index. mfg zmi -- // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0676/846 914 666 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: EA39 8918 EDFF 0A68 ACFB 11B7 BA2D 060F 1C6F E6B0 // Keyserver: www.keyserver.net Key-ID: 1C6FE6B0
pgpqjLnd9j6Jg.pgp
Description: PGP signature
_______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
