Paul J Stevens wrote: > I think this discussion should move to dbmail-dev. > > I've already finished most of the singleton mimechunk storage :-) > > A bit raw around the edges, and only for sqlite atm. Stay tuned. > > Fully backward compatible: just add two tables like I stated. Using sha1 over > the whole of the file, fall back to old-style storage if new-style not > available. I guess the one doing the work gets to make the decisions... > > I wonder if keeping the old style stuff around would be worth it? It seems a wasteful performance hit that is only really needed during the transition. My vote is to make the new stuff "the way" and take the downtime hit. With any luck the change should be pretty stable and be around for quite a while. > In this new setup; simple rfc2822 messages are stored in a single block. Yes: > no > more chopping off of the headers. For multi-part messages, the first block > contains the rfc headers plus the mime-preamble. Following blocks contain the > mime-parts as-is. > Do you convert them from whatever encoding they are in back into a raw binary before storing them? My understanding is the encoding adds significantly to the size of the files over the wire. > Boundaries between parts are reconstructed at retrieval based on the boundary > used in the original message and stored in the first block. > > I'm using the sha1 code from the mozilla project (dual licence). It's what > Linus > uses in the GIT code, so it *must* be fast. > > Are we having fun yet? > > could be ;->
_______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
