[mdk-re] The Bat! / Linux / charsets / WINE / ...beer :)

[Maksim Otstavnov]

Hello Roman,

Saturday, January 13, 2001, 3:04:33 PM, you wrote:

RS> Максим! Ваши замечания были бы очень ценны! Для Вас - почтовый клиент один
RS> из необходимых рабочих инструментов, для меня так же, но весьма специфично
RS> - в работе я пользуюсь кучей приложений, сделанных для Notes - без них я
RS> как без рук.

RS> Не могли бы Вы рассказать, ЧТО должен уметь универсальный почтовый клиент,
RS> который устроит Вас?
RS> Не важно, как ИМЕННО будут реализованы возможности - интегрированы ли в
RS> MUA или, скажем сделаны удобоваримым для конечного пользователя
RS> интерфейсом к другим средствам...
RS> Важно, КАКАЯ нужна функциональность....

Я (по устройству своей головы) не знаю, как обсуждать функциональность
отдельно от более глубоких архитектурных вопросов. Особенно, если речь
идет о таком запущенном случае, как сегодняшнее почтовое хозяйство.

Традиционно почтовые сервисы декомпозируются на три компонента: MTA,
MDA и MUA. "Сечения" между ними, в общем-то, описаны и разжеваны.

1. Проблема в том, что есть неочевидные интерфейсы. Один из них - от
MUA к подсистеме _хранения_ _полученных_ сообщений. Когда-то у нас был
mbox с известным форматом, и это решало все вопросы. Сейчас понятно,
что в большинстве случаев разумнее хранить почтовые массивы в БД.
Нужно эксплицировать этот интерфейс и описать его. Жить станет легче.

Это нетривиально, поскольку к нему требования противоречивые: он
должен быть узким и быстрым (чтобы можно было оптимально организовать
локальное хранение) и в то же время достаточно общим и мощным. Если бы
не было первого требования, можно было бы использовать IMAP как он
есть - там заложена и возможность такого его использования.

Возможно, что стоит подумать просто о введении четвертого агента -
MSA (mail starage agent) с прописанным интерфейсом, а затем
реализовать dual implementation - один раз к специфической _очень
быстрой_ БД, другой раз - как фильтр в SQL. Кстати, фильтры для
импорта из всякой проприетарной ерунды писать станет тоже гораздо
проще.

2. Второй "скрытый" интерфейс - это фактически неизбежное обращение
пользователя не только к сообщениям, но так же и к системе настройки
других агентов. Например, если для фильтрации используется procmail,
ad hoc донастройка фильтров есть часть скорее использования, чем
администрирования системы. Очень неплохо было бы иметь некий "язык
обработки почты" - наследник синтаксиса mail/xmail/mailx... в котором
это бы тоже было.

Полагаю, что по решении этих вопросов разработка интерфейсов MUA
станет много легче. До того, как они решены (или предложено другое
решение) "толстые" MUA (типа The Bat!) будут оставаться прагматичным
решением, предоставляющим функциональность "все в одном", хотя и при
плохой архитектуре.

"Плюха" The Bat! в том, что функциональность фильтров непонятно как
достать мимо GUI. Все остальные функции достаются. А ручками
распихивать параметры фильтров по окошкам... неаккуратненько. "Плюха"
- конечно - на фоне достаточно мощного самого по себе механизма
фильтрования.

3. Итого:

пользовательские интерфейсы
       -------------
   язык обработки почты
       -------------
           [сети]
       -------------
     {MSA}  MDA    MTA
       -------------
           [сети]
   
При этом "формулы" применения будут самыми разными. Для изолированной
dialup-машинки это будет (MUA+MSA)-dialup-(MDA+MTA)-Internet, для
офисной станции (MUA)-lan-(MSA+MDA+MTA)-Internet или
(MUA+MSA)-lan-(еще+_один_MSA+MDA+MTA)-Internet, для мобильного
пользователя - еще что-то.

-- 
-- Maksim