Paul J Stevens wrote: > Aaron Stone wrote: > >> I think we should keep things encoded, because that's what clients >> expect to receive. OTOH, encoded data cannot be searched. >> > > I don't see how we can do both decoding and sha1 digests reliably at the > same time. Seems like asking for a *lot* of trouble that is simply not > worth it. > > With all the talk of reducing file size I taught a basically free 30% reduction would be worth it lol. I don't see why it is so difficult if you are already seperating the chunks? Does it not tell you if that chunk is encoded? If it is then decode it, then hash it then store it.
It wouldn't be on the fly but since the whole message is assembled anyway before it gets sent to the database I don't see the big issue? (IE trying to halt a memory copy at the expense of a 30% reduction in write to disk doesn't sound worth it to me) > Doing search on binary attachments is not required by any RFC, and if > required should be done through a separate decode/stringify/index setup > (check the wiki). > I agree with you there, there isn't a valid reason i can come up with for an end user wanting to search a binary attachment. Although especially with the adoption of plain text file formats for documents I can see that becoming a potentially winning feature. I have often been in the situation of needing to find a particular document somebody emailed amidst four bazillion (hah bazillion passes spell check) other emails from them about the same time. If the mime parts are decoded then they could conceivably use the same fulltext indexing the message bodies use?
_______________________________________________ Dbmail-dev mailing list [email protected] http://twister.fastxs.net/mailman/listinfo/dbmail-dev
