Re: IMAP сервер на базах данных с прибабахами...
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 -- наглядный
пример почему собственные форматы работают.
Reply to: