Комментарии 56
Вопрос, а какой клиент с Вашей точки зрения вы рекомендуете?
я сейчас пользуюсь rhu8nderbird и многим недоволен, хочу чего-то «быстрее», что бы вы порекомендовали?
я сейчас пользуюсь rhu8nderbird и многим недоволен, хочу чего-то «быстрее», что бы вы порекомендовали?
+3
А какая платформа: windows/linux/mac os x, что именно не устраивает в скорости? Я лично imap-ом на android-е в основном пользуюсь, использую aquamail.
+3
windows, thunderbird
на ящиках свыше 10к писем очень медленно работает :)
на ящиках свыше 10к писем очень медленно работает :)
0
Хоть я сам лично и не фанат, но очень многие хвалят outlook :) Он вроде бы нормально работает с большой базой писем. Еще как вариант есть the bat и opera. Друзья использовали the bat + imap на довольно больших аккаунтах.
Для меня идеален был бы десктопный клиент с моделью работы мобильных клиентов: не качать ничего лишнего, всякие аттачи и картинки fetch-ить по запросу. Особенно это было бы актуально в случае слабого internet-канала. К сожалению, я таких клиентов не встречал, поэтому для десктопа использую веб-интерфейс. Он примерно соответствует моим требованиям не качать ничего лишнего.
Для меня идеален был бы десктопный клиент с моделью работы мобильных клиентов: не качать ничего лишнего, всякие аттачи и картинки fetch-ить по запросу. Особенно это было бы актуально в случае слабого internet-канала. К сожалению, я таких клиентов не встречал, поэтому для десктопа использую веб-интерфейс. Он примерно соответствует моим требованиям не качать ничего лишнего.
+2
Можно настроить, качать только заголовки писем, почти в любом клиенте.
Я тоже письмо не полностью качаю. У меня стоит SSD HDD и я просто экономию место.
Я тоже письмо не полностью качаю. У меня стоит SSD HDD и я просто экономию место.
0
Ну заголовки — это тоже может быть достаточно много, особенно, в случае, если это автогенеренные текстовые письма. А заголовки 100-200 тыс писем — это уже прилично данных само по себе. Их надо уметь прилично индексировать, с чем не всегда клиенты справляются.
Мобильные клиенты такой кучи информации стараются не хранить, а получают только последние сообщения, что мне и нравится.
Мобильные клиенты такой кучи информации стараются не хранить, а получают только последние сообщения, что мне и нравится.
0
Хорошая статья, систематизировали все проблемы imap.
+4
Витя, супер, респект за IMAP. Хорошая работа!
+7
Спасибо, очень интересно! Лишний раз подтверждает, что на практике все «немного не так», как написано в RFC.
+1
Вопрос не совсем по теме, но весьма меня волнующий.
mime вложений, разсширение, magic проверяются у вас уже или пока нет?
Помню, полгода назад с этим были проблемы. У gmail не было.
mime вложений, разсширение, magic проверяются у вас уже или пока нет?
Помню, полгода назад с этим были проблемы. У gmail не было.
0
К сожалению, не совсем понял, о чем речь. Плюс, полгода назад у нас имап, насколько помню, еще был только на внутреннем тестовом сервере и проблем там было море :)
Если речь об ответах BODY/BODYSTRUCTURE, то, согласно RFC, мы там возвращаем все поля из письма, которые клиенты могут использовать для работы с вложениями: content-id, content-type с полями charset и name, content-disposition с полем filename.
Если речь об ответах BODY/BODYSTRUCTURE, то, согласно RFC, мы там возвращаем все поля из письма, которые клиенты могут использовать для работы с вложениями: content-id, content-type с полями charset и name, content-disposition с полем filename.
+1
Писали мы клиент, который отправляет пользователю счет (с инн \ кпп, пасьянсом и барышнями) формате pdf. Использовали для сего действия gen_smtp.
Все три письма идентичны и все с вложениями. Только для последнего (первого в списке) был указан параметр application=pdf. Content-Type во всех случаях был application/pdf.
Что конкретно, мы отправлялось, не проверяли.
Если, любопытно, могу и покопаться.
Такая проблема была (и есть?) только у mail.ru.
Извиняюсь за офтоп (хотя вся ветка — оффтоп),
но на всякий пожарный приведу код:
Все три письма идентичны и все с вложениями. Только для последнего (первого в списке) был указан параметр application=pdf. Content-Type во всех случаях был application/pdf.
Что конкретно, мы отправлялось, не проверяли.
Если, любопытно, могу и покопаться.
Такая проблема была (и есть?) только у mail.ru.
Извиняюсь за офтоп (хотя вся ветка — оффтоп),
но на всякий пожарный приведу код:
mail( {FromName, FromEmail},
{ToName, ToEmail},
Subject,
Body,
{AttachName, AttachBinary}
) ->
Email = {<<"multipart">>, <<"mixed">>, [
{<<"From">>, mmh_person(FromName, FromEmail)},
{<<"To">>, mmh_person(ToName, ToEmail)},
{<<"Subject">>, list_to_binary(Subject)}],
[],
[
%% Тело письма
{<<"text">>,<<"plain">>, [], [], list_to_binary(Body)},
%% Аттачменты(PDF)
{<<"application">>,<<"pdf">>,
[{<<"Content-Type">>,<<"application/pdf">>},
{<<"Content-Transfer-Encoding">>,<<"base64">>}],
[
{<<"content-type-params">>,
[{<<"name">>, list_to_binary(AttachName)}],
[{<<"x-unix-mode">>,<<"0644">>}]},
{<<"disposition">>,<<"attachment">>},
{<<"disposition-params">>,[{<<"filename">>,
list_to_binary(AttachName)}]}],
AttachBinary}
]},
gen_smtp_client:send(
{
FromEmail,
[ToEmail],
mimemail:encode(Email)
}, ?SYS_MAIL_OPTIONS
).
0
Ага, т.е. речь все-таки об SMTP сервере. Я слишком плохо знаком с erlang-ом, чтобы суметь легко попробовать этот пример. Не могли бы вы сгенерить тела этих двух писем (с глюком и без), положить их в zip-архив и прислать мне на v.starodub {собака} corp.mail.ru? Мы разберемся, где именно глюк — в телах писем, или же в SMTP/веб-интерефейсе, если у нас — то с радостью починим.
Как я понимаю, генерацию производит вызов mimemail:encode(), а gen_smtp занимается уже отправкой?
Как я понимаю, генерацию производит вызов mimemail:encode(), а gen_smtp занимается уже отправкой?
+1
SMTP сервере.— Клиенте.
Gen_smtp занимается отправкой, но только в качестве клиента. Отправкой занимается sendmail (как я понимаю), который находится удаленно.
Остальное, вы поняли правильно.
Возможно, как верно подметил ниже Макс, это как раз пример такого «чу́дного клиента».
Попробую сделать что вы сказали.
0
Думаю, что тут вряд ли дело в клиенте, т.к. SMTP — очень агностичный протокол по отношению к телу письма, smtp-клиенту редко нужно уметь парсить mime письма дальше нескольких хэдеров и вообще разбираться, что там внутри. Исключение составляет только разве что binary extension.
Нужно смотреть в тело письма.
Нужно смотреть в тело письма.
+1
Если я воспроизвел именно ту ошибку о которой говорил, то я немного соврал. Уж слишком давно это было. Да и во общем, вроде уже проблему решили, не актуально.
Проболема была в
— странно, и несколько не предсказуемо.
Пока пытался воспроизвести, эту проблему я нашел, еще несколько интересных особенностей. Сервисы на которых, я тестировал почту были выбраны от балды (никаких предрассудков и предрасположенностей не имею), просто нужно было с чем-то сравнивать.
Несколько урезанные версии писем на которых тестировалось:
gist.github.com/b5bb40d982604b40b5b7
Полные версии продублировал на почту.
Проболема была в
multipart/alternative
. Т.о., с вашей стороны все было сделано, формально правильно. Однако, поведение, интерфейса почты — странно, и несколько не предсказуемо.
Пока пытался воспроизвести, эту проблему я нашел, еще несколько интересных особенностей. Сервисы на которых, я тестировал почту были выбраны от балды (никаких предрассудков и предрасположенностей не имею), просто нужно было с чем-то сравнивать.
- Если указать,
multipart
неmixed
, aalternative
, в mail.ru вложение приходит то в гриде просмотра почты не отображается, что есть вложение. У mail.yandex.ru показывает, что вложение есть, но в письма вложения вообще нет (скачивать нечего). То, что вложение есть показывается не сразу после получения письма, а если немного подождать. У gmail.сom все ок.
Если я действительно, воспроизвел ту самую проблему, понятно, почему у mail.yandex.ru она не была замечена. Не факт, что внутрь письма заглядывали, когда тестировали полгода назад.
- Была замечена ошибка у mail.yandex.ru. Если отправлять письмо без,
Content-Transfer-Encoding: base64
то в гриде просмотра почты не отображается, что есть вложение. Всего скорее проблемы в интерфейсе. Потому что поcле просмотра письма значок аттача появляется. У mail.ru все ок. У gmail.сom все ок. - Если не указать
disposition-params
у mail.ru, то нет аттача в гриде просмотра почты. Если открыть само письмо, то аттач есть (Untitled.pdf вместо имени). Проблема всего скорее только в интерфейсе, ибо thunderbird этот аттач видит и до открытия письма. У mail.yandex.ru в этом случае вообще не показывает аттача. У gmail.сom все ок, но вложение соответсвенно называется noname (без расширения). - Была замечена ошибка у mail.yandex.ru Если отправлять письмо без,
content-type-params
, то в гриде просмотра почты не отображается, что есть вложение. У mail.ru все ок. У gmail.сom все ок.
Несколько урезанные версии писем на которых тестировалось:
gist.github.com/b5bb40d982604b40b5b7
Полные версии продублировал на почту.
0
Молодцы!
Полагаю, что вам ещё год-два знакомиться с разными диалектами чудных клиентов, которые шлют команды именно в таком порядке, в котором вы уж точно никак не рассчитывали, но вы и это разберете =)
Насколько вам пришлось менять само базовое хранилище писем? К нему централизованный доступ или вы запускаете на каждом сервере со стораджами свой IMAP сервер?
Полагаю, что вам ещё год-два знакомиться с разными диалектами чудных клиентов, которые шлют команды именно в таком порядке, в котором вы уж точно никак не рассчитывали, но вы и это разберете =)
Насколько вам пришлось менять само базовое хранилище писем? К нему централизованный доступ или вы запускаете на каждом сервере со стораджами свой IMAP сервер?
+2
Спасибо :)
К хранилищу пришлось прикрутить imap-ные uid-ы и uidvalidity, а также их обновление в случае модификаций писем. Это теоретически несложно, но нужно было быть аккуратным и поправить достаточное кол-во кода. Также там была прикручена пара оптимизаций для ускорения частичной отдачи письма в RFC-формате, это не было нужно pop3 и веб-интерфейсу.
Вообще, одна из целей написания собственного сервера — не менять сильно хранилище, т.к. переиндексировать все письма — очень «дорого», в наших объемах это может занять до полугода. Мы обошлись только довольно «дешевой» раздачей uid-ов, которую мы делаем при первом доступе по imap к ящику.
Хранилище у нас на отдельных серверах, имап является таким же клиентом хранилища, как и pop3, smtp и веб-интерфес. Они все дергают один API по одному протоколу.
К хранилищу пришлось прикрутить imap-ные uid-ы и uidvalidity, а также их обновление в случае модификаций писем. Это теоретически несложно, но нужно было быть аккуратным и поправить достаточное кол-во кода. Также там была прикручена пара оптимизаций для ускорения частичной отдачи письма в RFC-формате, это не было нужно pop3 и веб-интерфейсу.
Вообще, одна из целей написания собственного сервера — не менять сильно хранилище, т.к. переиндексировать все письма — очень «дорого», в наших объемах это может занять до полугода. Мы обошлись только довольно «дешевой» раздачей uid-ов, которую мы делаем при первом доступе по imap к ящику.
Хранилище у нас на отдельных серверах, имап является таким же клиентом хранилища, как и pop3, smtp и веб-интерфес. Они все дергают один API по одному протоколу.
+2
детский сад :)
-5
В Outlook 2013 добавили RFC6154 XLIST
0
>Уже некоторое время IMAP работает в Почте Mail.Ru в полную силу
Гмайл IMAP с 2008 г.
Яндекс IMAP с 2009 г.
Про IMAP на Mail.Ru в 2012 смешно читать, как и о почте на Mail.Ru, уж извините, хотя за статью спасибо.
Гмайл IMAP с 2008 г.
Яндекс IMAP с 2009 г.
Про IMAP на Mail.Ru в 2012 смешно читать, как и о почте на Mail.Ru, уж извините, хотя за статью спасибо.
-7
Я рад, что наша статья вызывает у вас положительные эмоции. Сейчас обхохочетесь еще больше:
Newmail.ru IMAP с 2001 г.
Hotbox.ru IMAP с 2002 г.
Gmail IMAP с 2008 г.
Обе почте несколько лет назад объединились в составе mail.qip.ru и здравствуют и поныне.
Newmail.ru IMAP с 2001 г.
Hotbox.ru IMAP с 2002 г.
Gmail IMAP с 2008 г.
Обе почте несколько лет назад объединились в составе mail.qip.ru и здравствуют и поныне.
+3
Вы Hotbox.ru и Newmail.ru ставите в один ряд с Gmail, Яндекс, Mail.Ru, тогда давайте начнем с 86?
+1
Обе эти почты — это сейчас mail.qip.ru, которая по российской дневной аудитории где-то на уровне Rambler-почты, т.е. четвертая почта после Mail.Ru, Yandex и GMail. mail.qip.ru, конечно, по российской суточной аудитории отличается в разы от ближайшего к ней GMail, но и GMail в разы меньше Mail.Ru по тому же параметру.
0
ключевое слово «сейчас». И какое в данном контексте имеет значение российская аудитория или нет?
0
Как раз в те годы, когда там внедряли имап, эти сервисы были достаточно популярны, не только сейчас. Навскидку: у меня именно в 2001-м основной ящик был на newmail.ru, как и у многих моих друзей.
Актуальность имапа тогда была достаточно высока: веб-интерфейсы были убогие по современным меркам, почтовые программы были бесспорно удобнее. Интернет был дорогой и слабый, возможность не качать весь свой ящик, работать с папками на сервере выглядела достаточно привлекательно. Поддержка имапа этими сервисами в своем роде даже большее достижение, чем имап на гмейле в 2008-м.
Но если говорить именно про «сейчас», так в современном своем виде имап более актуален для мобильных клиентов, которые в силу своих ограничений по объему persistent-хранилища просто не могут адекватно работать с pop3. Если посмотреть на графики, то мобильных клиентов больше половины.
Но нормальная поддержка имапа, более-менее соответствующая RFC и работающая не только с gmail-ом и еще парой серверов, например, в андроиде появилась чуть позже появления версии 2.2, а это был уже 2010 год. В 2008-м не было такого рынка устройств, корректно поддерживающих imap, соответственно актуальность самого протокола была не так высока.
С 2008 года поменялось многое: команда почты mail.ru поменялась практически целиком, как поменялись и приоритеты. К сожалению, я не мог написать имап в 2008 году, как бы ни хотел, т.к. я еще тогда не работал в команде почты и в mail.ru вообще, а Денис тогда как раз делал поддержку имапа в яндексе :)
В своем посте я систематизировал технические нюансы реализации imap-а. Возможно, кому-то это будет просто любопытно, кому-то подкинет мыслей, скажем, при написании imap-клиента. Если бы я что-то в этом роде прочитал перед написанием сервера — мне это бы сэкономило некоторое количество времени. Если вам это неинтересно и вызывает лишь скептицизм — простите меня за то, что вы решили прочесть эту статью.
Актуальность имапа тогда была достаточно высока: веб-интерфейсы были убогие по современным меркам, почтовые программы были бесспорно удобнее. Интернет был дорогой и слабый, возможность не качать весь свой ящик, работать с папками на сервере выглядела достаточно привлекательно. Поддержка имапа этими сервисами в своем роде даже большее достижение, чем имап на гмейле в 2008-м.
Но если говорить именно про «сейчас», так в современном своем виде имап более актуален для мобильных клиентов, которые в силу своих ограничений по объему persistent-хранилища просто не могут адекватно работать с pop3. Если посмотреть на графики, то мобильных клиентов больше половины.
Но нормальная поддержка имапа, более-менее соответствующая RFC и работающая не только с gmail-ом и еще парой серверов, например, в андроиде появилась чуть позже появления версии 2.2, а это был уже 2010 год. В 2008-м не было такого рынка устройств, корректно поддерживающих imap, соответственно актуальность самого протокола была не так высока.
С 2008 года поменялось многое: команда почты mail.ru поменялась практически целиком, как поменялись и приоритеты. К сожалению, я не мог написать имап в 2008 году, как бы ни хотел, т.к. я еще тогда не работал в команде почты и в mail.ru вообще, а Денис тогда как раз делал поддержку имапа в яндексе :)
В своем посте я систематизировал технические нюансы реализации imap-а. Возможно, кому-то это будет просто любопытно, кому-то подкинет мыслей, скажем, при написании imap-клиента. Если бы я что-то в этом роде прочитал перед написанием сервера — мне это бы сэкономило некоторое количество времени. Если вам это неинтересно и вызывает лишь скептицизм — простите меня за то, что вы решили прочесть эту статью.
+1
Как справедливо заметил Витя эти почты тогда занимали существенную долю рынка. Т.е. сейчас — это не ключевое слово. Российская аудитория имеет то значение, что вы упомянули gmail, у которого суточная аудитория world wide выше mail.ru в 4 раза. Если вы считаете их нашими конкурентами, то неявно подразумеваете, что речь только о России и возможно бывших советских республиках.
0
В Mail.Ru первый раз IMAP был запущен в 2005 году. И вполне успешно работал с популярными почтовыми клиентами того времени. Но популярность среди пользователей протокол не обрел, да и те кто им пользовался не охотно репортили баги, поэтому из-за отсутствия обратной связи с пользователями, и развитие поддержки имапа на стороне клиента ушло дальше возможностей имапа Mail.Ru. Повторный интерес к IMAP на мой взгляд — появился одновременно с ажиотажем на устройства с iOS и android. Появился интерес вот вам и обновленный IMAP 2012 Mail.Ru :)
+2
Спасибо за статью! А можно вкратце про dovecot — помимо сложностей с прикручиванием к хранилищу, какие ещё с ним были проблемы? От него пришлось отказаться в основном из-за хранилища, или это была только половина проблемы?
+1
В основном из-за хранилища. Но dovecot еще и очень прожорлив по процессору
0
мне кажется, что IMAP-сервер это как раз то, что надо садиться и писать на эрланге без всяких там глупостей с С =)
Логики много, она вся с таймаутами и запутанная.
Логики много, она вся с таймаутами и запутанная.
+2
Если говорить про написание просто абстрактно хорошего имап сервера, оно, наверное, так и есть: проще взять очень высокоуровневый, возможно функциональный, язык программирования, написать на нем лаконичный, красивый и аккуратный код без хаков.
Но у нас сервер, к сожалению, писался не совсем абстрактно: есть уже хранилище с достаточно громоздким C-шным API, кроме того, внутри проекта почты сервер-сайд сейчас пишут на С/C++, perl-е и python-е. Программистов на эрланге у нас в команде просто нет. Т.е. даже если сервер на нем и написать, то читать его код будет потом некому. Плюс, надо изобретать какие-то обертки для C-шного кода в эрланг, либо поддерживать 2 версии клиентской библиотеки к стороджу.
В общем тут как обычно, для нас самым большим ограничением было то, что у проекта почты уже большая история, очень много всего уже написано. Не хотелось, во-первых, плодить зоопарка из технологий, а во-вторых, дублировать уже существующий код.
Да и на самом деле, на C++ при правильном подходе, код оказался довольно лаконичным: со всеми хаками для всех клиентов, там имапной специфики около 5000 строк. :)
Но у нас сервер, к сожалению, писался не совсем абстрактно: есть уже хранилище с достаточно громоздким C-шным API, кроме того, внутри проекта почты сервер-сайд сейчас пишут на С/C++, perl-е и python-е. Программистов на эрланге у нас в команде просто нет. Т.е. даже если сервер на нем и написать, то читать его код будет потом некому. Плюс, надо изобретать какие-то обертки для C-шного кода в эрланг, либо поддерживать 2 версии клиентской библиотеки к стороджу.
В общем тут как обычно, для нас самым большим ограничением было то, что у проекта почты уже большая история, очень много всего уже написано. Не хотелось, во-первых, плодить зоопарка из технологий, а во-вторых, дублировать уже существующий код.
Да и на самом деле, на C++ при правильном подходе, код оказался довольно лаконичным: со всеми хаками для всех клиентов, там имапной специфики около 5000 строк. :)
+1
Плюс, надо изобретать какие-то обертки для C-шного кода в эрланг
Для таких вещей все и придумывалось. Наш стримящий сервер был написан тоже в лохматые времена на C. Не мешает его испрльзовать через erlang. Тем более, не надо ничего изобретать!
www.erlang.org/doc/tutorial/c_port.html
Реальный пример использования:
github.com/zavr/erlxslt (многопоточная обертка над libxslt)
Программистов на эрланге у нас в команде просто нет.
Вопрос двух недель. У нас тоже не было.
Если Вы любите, TeX, пример — есть такие хорошие понятия в TeX как «блоки» и «клей». В переложении на мир технологий, erlang — и есть этот «клей». Это не просто еще один язык разработки, в том-то и его преимущество (мы же Вам не ocaml или haskell предлагаем).
Можно писать, на самом erlang все, но если уже что-то есть сделанное, не обязательно переписывать. Составные части, как мне кажется, логично продолжить писать на сях, а вот склеивать их эрлангом. Но это мое скромное мнение.
Вам, в вашей ситуации виднее.
0
Ну, т.е. с_port подразумевает еще один процесс-проксю? Не думаю, что наших админов бы это обрадовало :)
А на самом деле, я думаю, что описанный вами способ написания сервера — просто другой подход, который вполне хорош и имеет право на жизнь. Он имеет, как плюсы, так и минусы.
Вообще же, как показала практика, написать код сервера — это не так уж и сложно, независимо от языка. Повторюсь, но специфики имап там всего лишь 5к строчек. Правильно подружить все это дело с нашей инфраструктурой, с множеством разных клиентов — это было куда более сложной задачей, а тут уже язык не важен, важен подход.
А на самом деле, я думаю, что описанный вами способ написания сервера — просто другой подход, который вполне хорош и имеет право на жизнь. Он имеет, как плюсы, так и минусы.
Вообще же, как показала практика, написать код сервера — это не так уж и сложно, независимо от языка. Повторюсь, но специфики имап там всего лишь 5к строчек. Правильно подружить все это дело с нашей инфраструктурой, с множеством разных клиентов — это было куда более сложной задачей, а тут уже язык не важен, важен подход.
+1
c_port как вариант, а так, как настроите-сделаете. Обычно, да — но, это вроде как логично, но все настраиваемо. Может и erl_driver замутить.
Я во общем вас не агитирую, просто ответил, на не очень правильные аргументы с вашей стороны. А у программы все один критерий правильности: работает — значит не все плохо.
Ближе к теме:
5k хорошо комментированного, понятного кода, или как голые функции, c короткими именами и однобуквенные переменные?
Я во общем вас не агитирую, просто ответил, на не очень правильные аргументы с вашей стороны. А у программы все один критерий правильности: работает — значит не все плохо.
Ближе к теме:
5k хорошо комментированного, понятного кода, или как голые функции, c короткими именами и однобуквенные переменные?
0
Как это нет? Вот у вас есть люди, которые пишут сервер-сайд на С++? Они уже готовы писать на эрланге, пока компилится С-шный код.
+1
Хм, ну уж нет. Я, например, лично не готов :) Толстовато, в общем)
Вообще, это странная тема… я могу более-менее читаемо, быстро и лаконично писать на C++(надеюсь, что так). Вы — на erlang. Если мы поменяемся местами, то, скорее всего, наша продуктивность резко снизится (во всяком случае, моя уж точно). Хуже от этого будет только пользователям mail.ru, которые получат имап позже :) При этом, при всех прелестях erlang-а, вряд ли я сразу напишу maintainable код.
А кроме erlang-а еще много интересных технологий. Говорят, в последнем .NET-е интересные фишки в плане асинхронности добавили, а еще он тоже быстро компилируется. Scala тоже интересный и красивый язык с функциональными плюшками.
Но если все пробовать, то кто и когда код писать-то будет? Да и по мне, так добавление еще одного языка, даже самого передового, в любой корпоративный зоопарк технологий только усложняет интеграцию.
Вообще, это странная тема… я могу более-менее читаемо, быстро и лаконично писать на C++(надеюсь, что так). Вы — на erlang. Если мы поменяемся местами, то, скорее всего, наша продуктивность резко снизится (во всяком случае, моя уж точно). Хуже от этого будет только пользователям mail.ru, которые получат имап позже :) При этом, при всех прелестях erlang-а, вряд ли я сразу напишу maintainable код.
А кроме erlang-а еще много интересных технологий. Говорят, в последнем .NET-е интересные фишки в плане асинхронности добавили, а еще он тоже быстро компилируется. Scala тоже интересный и красивый язык с функциональными плюшками.
Но если все пробовать, то кто и когда код писать-то будет? Да и по мне, так добавление еще одного языка, даже самого передового, в любой корпоративный зоопарк технологий только усложняет интеграцию.
+1
А как же синергетический эффект? )
К сожалению, особенности .NET и java-машины, не позволяют, на мой взгляд, сделать полноценную асинхронность. Во общем, есть на то математические основания.
Возможно, а возможно и раньше. + есть одна важная деталь — сопровождение. Не только сегодняшним днем живем. И не в любых своих (и чужих) исходниках двухлетней давности приятно разбираться.
Как раз для изучения плюсов и минусов той или иной технологии, применительно к текущим задачам и нужны в компании консультанты.
в плане асинхронности добавили
К сожалению, особенности .NET и java-машины, не позволяют, на мой взгляд, сделать полноценную асинхронность. Во общем, есть на то математические основания.
получат имап позже
Возможно, а возможно и раньше. + есть одна важная деталь — сопровождение. Не только сегодняшним днем живем. И не в любых своих (и чужих) исходниках двухлетней давности приятно разбираться.
Как раз для изучения плюсов и минусов той или иной технологии, применительно к текущим задачам и нужны в компании консультанты.
0
В плане .NET — я на нем писал давно и не очень много. Но об этих улучшениях написано в release notes, друзья говорили, что стало удобнее. Это был просто пример того, что есть и другие интересные технологии, которые в принципе можно попробовать :)
Получат позже — потому что непосредственно написание кода заняло реально малый процент времени. Я знаю, что на новом для себя языке я бы писал не так быстро и код был бы хуже, как минимум, первые полгода. На нормальное овладение технологией, имхо, уходит не один месяц и не один проект.
Я лично, как инженер, считаю, что язык программирования — не главное. На практически любом языке можно сделать удобную для проекта и задач платформу. Главное — хорошо владеть выбранным инструментом.
Консультанты — это хорошо, но я помню, что в Parallels, например, по совету консультантов начали пытаться переписывать всю автоматизацию на java. Имхо, это был очень странный шаг, который стоил компании нескольких толковых специалистов и отнял порядочно времени. С любым подходом главное — не перестараться :)
Получат позже — потому что непосредственно написание кода заняло реально малый процент времени. Я знаю, что на новом для себя языке я бы писал не так быстро и код был бы хуже, как минимум, первые полгода. На нормальное овладение технологией, имхо, уходит не один месяц и не один проект.
Я лично, как инженер, считаю, что язык программирования — не главное. На практически любом языке можно сделать удобную для проекта и задач платформу. Главное — хорошо владеть выбранным инструментом.
Консультанты — это хорошо, но я помню, что в Parallels, например, по совету консультантов начали пытаться переписывать всю автоматизацию на java. Имхо, это был очень странный шаг, который стоил компании нескольких толковых специалистов и отнял порядочно времени. С любым подходом главное — не перестараться :)
+1
Это ветка, конечно, похожа на холивар, но Вы приводите интересные и очень разумные аргументы, потому предлагаю продолжить.
Знание внешней оболочки языка, без понимания основания делает человека «языковым чудищем». Вы просто спросили как пройти, а вам морду набили.
Парадигмы-то они эквивалентны, но некоторые вещи в лямда выражениях выглядят проще, удобнее, эффективнее, чем в рамках стековой машины (java, .net, python) или машины фон Неймана (C\C++, Fortran).
Локальные решения это хорошо, но только они не позволяют находить других локальных решений, которые, может быть, лучше. Траншею можно копать саперной лопаткой, а можно экскаватором. Если траншея одна в принципе, то лопатой, конечно быстрее. Она получится даже аккуратнее. А на экскаваторщика придется еще учиться. Но если траншей сотни, то лопата уже не применима.
Получат позжеЯ с Вами согласен, что применять что-то пилотное в активном и критически важном проекте — не правильно. Но, как мне кажется, нужно смотреть дальше чем один проект. Живем не сегодняшним днем, и Ваши 5k строк через некоторое время могут превратиться в 50k, 500k строк (и это нормально) и их надо будет как-то поддерживать. Если есть немного свободного времени, посмотрите Cesarini F. Erlang programming, и сравните с тем что уже имеете.
язык программированияСогласен, но как лингвист, я скажу что любые языки принципиально не эквивалентны. Сам язык, что — просто набор правил над некоторым множеством символов. Но за каждым естественным языком стоит его культура. За искусственным — парадигма, или архитектура абстрактной машины этого языка.
Знание внешней оболочки языка, без понимания основания делает человека «языковым чудищем». Вы просто спросили как пройти, а вам морду набили.
Парадигмы-то они эквивалентны, но некоторые вещи в лямда выражениях выглядят проще, удобнее, эффективнее, чем в рамках стековой машины (java, .net, python) или машины фон Неймана (C\C++, Fortran).
сделать удобную для проекта и задач платформуПо сути, тоже реализация некоторого языка, на основе существующего. А такое лучше делать на функционального подхода. + Делать платформу — это тоже время. А если она станет одноразовой, и даже частично не применимой, к чему-то другому — слишком дорого.
Локальные решения это хорошо, но только они не позволяют находить других локальных решений, которые, может быть, лучше. Траншею можно копать саперной лопаткой, а можно экскаватором. Если траншея одна в принципе, то лопатой, конечно быстрее. Она получится даже аккуратнее. А на экскаваторщика придется еще учиться. Но если траншей сотни, то лопата уже не применима.
0
пока компилится С-шный код.
Вот тут мне кажется, ты не прав. Что такое у тебя долго компилировалось? И как долго?
Имхо, такие 5k как раз, скомпилятся вполне себе быстро.
0
Посмотрел на dovecot — там вроде бы вполне прозрачная система плагинов для хранилищ. Неужели настолько плохо совместимыми оказались его API и API хранилища — настолько, что написать с нуля сервер оказалось дешевле? Или, как ответили выше, процессорное время тоже стало узким местом (или ещё что-то)?
+1
В общем случае, dovecote надо допиливать напильником, если у вашего хранилища ни один из поддерживаемых им форматов. Вот тут подробности: wiki2.dovecot.org/MailboxFormat
Ну и процессорное время тоже жалко. В свое время, когда я работал техдиром в Почте.ру, у нас была IMAP-прокси в лице dovecote. Переделав ее на свою собственную, мы уменьшили количество серверов для IMAP-прокси в 10 раз.
Ну и процессорное время тоже жалко. В свое время, когда я работал техдиром в Почте.ру, у нас была IMAP-прокси в лице dovecote. Переделав ее на свою собственную, мы уменьшили количество серверов для IMAP-прокси в 10 раз.
0
Там основная проблема в том, что у нас другие требования к индексам. Как пример: imap-сервер может позволить себе сохранить в индексе уже готовый ответ на fetch bodystructure, для нас это было бы слишком дорого как в смысле избыточности, так и в смысле переиндексации. У нас структура письма в индексах хранится в виде дерева, и используется imap-ом, веб-интерфейсом, и даже pop3.
Кроме того, письма у нас хранятся не по RFC, а в другом, чуть более компактном виде.
Фактически нам надо было бы научиться формировать на лету ответы bodystructure/envelope из данных в нашем формате, прикрутить какие-нибудь хаки для того, чтобы без лишних оверхедов на I/O отдавать части письма, попутно преобразуя их к RFC-виду. Потом надо было бы прикрутить общение с нашей базой юзеров.
На самом деле, примерно этим и занимается 80-90%% кода нашего имап-сервера.Т.е. какую часть dovecot-а мы реально смогли бы переиспользовать? По сути, только работу с сокетами и парсинг протокола. И то, ее, скорее всего пришлось бы патчить, чтобы не есть лишнего CPU.
Кроме того, dovecot — сторонний для нас проект, он живет своей жизнью и любые плагины и правки нам надо будет мерджить с новыми изменениями самого сервера, либо взять на себя поддержку проекта из 300 тыс строк.
В результате плюсы от написания своего сервера перевесили минусы.
Кроме того, письма у нас хранятся не по RFC, а в другом, чуть более компактном виде.
Фактически нам надо было бы научиться формировать на лету ответы bodystructure/envelope из данных в нашем формате, прикрутить какие-нибудь хаки для того, чтобы без лишних оверхедов на I/O отдавать части письма, попутно преобразуя их к RFC-виду. Потом надо было бы прикрутить общение с нашей базой юзеров.
На самом деле, примерно этим и занимается 80-90%% кода нашего имап-сервера.Т.е. какую часть dovecot-а мы реально смогли бы переиспользовать? По сути, только работу с сокетами и парсинг протокола. И то, ее, скорее всего пришлось бы патчить, чтобы не есть лишнего CPU.
Кроме того, dovecot — сторонний для нас проект, он живет своей жизнью и любые плагины и правки нам надо будет мерджить с новыми изменениями самого сервера, либо взять на себя поддержку проекта из 300 тыс строк.
В результате плюсы от написания своего сервера перевесили минусы.
+1
Рапортую: IMAP работает просто великолепно. Подключил с первого раза без проблем. Огромное спасибо!
+1
Почему-то сейчас не могу установить для ящика возможность использовать IMAP, как на iOS 6 так и в Mail.App OS X 10.8.2. Всё время видится только POP3
0
Спасибо за статью. Хоть я и не программист, но было очень интересно почитать.
Кто что может посоветовать (из почтовых серверов) для компании (200 пользователей). Средний размер ящика 10 ГБайт (максимум — 30 ГБайт). Средне кол-во писем в ящике — 30000.
Сейчас используем dovecot. Клиенты — Thunderbird. У всех IMAP без кеширования почты на диск.
Спасибо!
Кто что может посоветовать (из почтовых серверов) для компании (200 пользователей). Средний размер ящика 10 ГБайт (максимум — 30 ГБайт). Средне кол-во писем в ящике — 30000.
Сейчас используем dovecot. Клиенты — Thunderbird. У всех IMAP без кеширования почты на диск.
Спасибо!
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
IMAP: трудности перехода