On Thu, Feb 17, 2005 at 10:57:28AM +0100, Sergey Spiridonov wrote: > В DBMail письмо не храниться одним большим блобом. Они режут тело письма > на куски по сколько-то килобайт.
http://www.dbmail.org/dokuwiki/media/dbmail-er-model.png Разделять письмо на какие-то бессмысленные килобайты на мой взгляд решено разума. СУБД вроде как должна абстрагировать от каких-то там блоков, дисков, байтов и др. низкоуровневой фигни. Хранение письма MIME-частями было бы гораздо понятнее (заголовки, тело, аттачменты). Любопытно, авторы сделали IMAP-флаги (seen, answered, recent,...) явными полями, а сабжекты сообщений зачем-то находу выдёргивают. > Динамический словарь с часто используемыми хедерами у них в TODO. Но > даже с уже перечисленными недостатками хранение почты в базе данных > даёт преимущества. Было бы интересно что ты видишь там преимуществами. Подавляющее большинство практических задач получения сообщений по критерию решают команды [UID] SEARCH, FETCH протокола IMAP. Как выбирать нужные письма из DBmail я вообще не понимаю. Руками писать SQL, в котором конкатенировать их килобайты письма и глазами парсить? Я читать даже QP не умею, не говоря уже о BASE64. > Недостатки mbox известны и очевидны, они породили maildir. Недостатки у > maildir тоже есть и тоже довольно очевидны. Например для получения > списка заголовков нужно открыть кучу файлов и прочитать их, в sql это > один select. В SQL это ещё специальный клиент или транслятор imap(pop) <-> sql. Текущие реализации всяких imap работают и так. > Самопальные форматы храненения отдыхают тоже по очевидным > причинам. Я вот таких "очевидных" причин не знаю. Более того, gmail -- наглядный пример почему собственные форматы работают. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
