On Sat, 2005-12-17 at 17:59 +0100, Thomas Mueller wrote: > > With a mime message like this: > > > > --b1 > > text > > --b1 > > rfc822 > > --b2 > > text > > --b2-- > > --b1-- > > > > Perhaps a parts layout similar to this: > > > > part,pre_boundary, content, encoding, post_boundary > > '1', 'b1', 'text', 'us-ascii', NULL, > > '2', 'b1', 'rfc822', NULL, NULL, > > '2.1', 'b2', 'text', 'base64', 'b2', > > NULL, NULL, NULL, NULL, 'b2', > > > > It would allow quick access to a section, searching of only parts we > > want (discovered at insert time), and make it pretty easy to reassemble > > the message if anyone asks... > > Yes something like that. That would break compatibility with 2.0 but > improve search performance a lot.
It wouldn't have to break compatibility! dbmail already allows you to split a message on parts- we could write a program to convert the physmessage parts into a new DB format that would be compatible with 2.0 - even if when 2.0 inserted new messages it would be broken again. The idea is really simple, just list each "chunk" separately: '--b1', 'text', '--b1', 'rfc822', '--b2', 'text', '--b2--', '--b1--', Then we'd add a flag (that 2.0 would ignore) to the rows columns telling dbmail what to do: A -> this is plain text (search on body) B -> this is a boundary (ignore) C[x] -> this is binary object 'x' (search other table or disk for pre-decoded part) -- absent would mean dbmail hadn't decoded it yet This would make it possible to search faster by doing work on insert WITHOUT making the database incompatible with 2.0... -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
