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