Re: функционал внешнего IMAP в mail web-frontend_ах
On Tue, Nov 05, 2013 at 10:17:56PM +0400, Victor Wagner wrote:
> On 2013.11.05 at 21:21:49 +0400, Eugene Berdnikov wrote:
>
> > > У меня несколько другое разделение. Я считаю что с диском MUA тоже
> > > работать не должен, за исключением операции сохранения аттачмента в
> > > файл. А так MUA - это клиент проткола IMAP.
> >
> > Ничем не обоснованный снобизм, IMHO... Так можно дойти до того, что
>
> Этот снобизм обоснован наличием RFC 5957 и его поддержки в Dovecot.
Вообще-то я про объектную модель писал. Вы же мне какие-то номера заявок
в техподдержку интернета и давленных котов подсовываете... :))
> А также различными вариантами индексирования почтовых ящиков.
Пользователя компьютера эта требуха интересует не более, чем детальки
машины Тюринга. :)
> Ну и к тому же если с одним и тем же ящиком одновременно работает
> локальный MUA и мобильный, то эта самая "лишняя" прослойка обеспечивает
> cooperative locking.
Только потому, что мобильный клиент не умеет работать с fs, ему нужна
подстилка в виде imapd.
> А то у dovecot есть такая вредная привычка -
> отдавать из своего индекса imap-клиенту в списке письма, удаленные локальным MUA
> по файловой системе. И только при повторном запросе списка
> спохватываться "Ах, у меня же в maildir этого нет".
Во-первых, блокировки здесь абсолютно не при чём. Здесь речь о выборке
свойств объектов, меняющихся со временем. Причём объект модифицируется
несколькими клиентами независимо и асинхронно, поэтому невозможно
заложиться на то, что свойства объекта при следующей операции будут
такие же, как после предыдущей. Чтобы это обеспечить, нужно реализовать
транзакции, это классика баз данных.
Транзакции реализуются с помощью блокировок, но наличие блокировок
не означает наличие транзакций.
Во-вторых, можно подумать, при одновременном доступе по imap что-то
будет происходить иначе... :/ Нет, не будет. Потому что транзакций нет,
а не потому что файловый API чем-то хуже сетевого протокола.
--
Eugene Berdnikov
Reply to: