В Вто, 17/03/2009 в 20:25 +0200, Тихон Тарнавский пишет: > On Tue, 17.03.2009 19:45:14 , Покотиленко Костик wrote: > > В Вто, 17/03/2009 в 18:25 +0300, Artem Chuprina пишет: > > > Покотиленко Костик -> [email protected] @ Tue, 17 Mar 2009 > > > 17:02:39 +0200: > > > > > > >> >> >> И что же парсит и преобразует telnet при работе в качестве > > > клиента > > > >> >> >> SMTP? > > > >> >> > > > >> >> ПК> Он то ничего не парсит, пользователя telnet'а приходится > > > парсить. > > > >> >> > > > >> >> Ты опять все понимаешь с точностью до наоборот. Пользователь > > > telnet > > > >> >> _имеет возможность_ провести диалог с сервером, не будучи > > > _вынужден_ для > > > >> >> этого пользоваться специальным инструментом. Который с шансами > > > будет > > > >> >> малость, а то и немалость, устаревшим, и поддерживать не все > > > особенности > > > >> >> протокола. > > > >> >> > > > >> >> Приведу в пример, скажем, swaks - отладчик для конфигурации SMTP. > > > У > > > >> >> которого мне, помнится, не удалось найти средства прервать диалог > > > после > > > >> >> команды DATA, но до вкармливания в сервер собственно письма. > > > >> >> > > > >> >> Так-то он весь из себя хороший, и пользоваться им для тестирования > > > >> >> конструкции со STARTTLS куда удобнее, чем руками... Но вот пары > > > нужных > > > >> >> фич не умеет - и до свидания. И что б я делал, будь там бинарный > > > >> >> протокол? Разбирался бы в его коде, чтобы туда эту возможность > > > >> >> дописать? А если бы он при этом еще и был написан с > > > использованием > > > >> >> сишной библиотеки реализации протокола, и этой возможности не > > > было бы в > > > >> >> _ее_ интерфейсе? > > > >> > > > >> ПК> Это вопрос дисциплины. Бинарь к ней, кстати, располагает все > > > сравнения с > > > >> ПК> текстом. > > > >> > > > >> Последнее предложение на русский переведи, пожалуйста. > > > >> > > > >> Впрочем, если ты так же пишешь и код, то можешь не переводить. > > > > > > ПК> сорьки. > > > > > > ПК> -все+вне > > > > > > Ага. Опять-таки, совершенно не согласен. Да, располагает. Но не к > > > той, которая нужна, а к той, где "за деревьями леса не видно". > > > > Заголовки этого письма составляют: 5189 байт > > Текст этого письма с подписями: 2104 байт > > КПД: 2104/(5189+2104)=~29% > > > > Письмо, я бы сказал, среднего размера. > > > > При мысли о том что мне придётся написать парсер заголовков мне никакой > > бинарь не страшен, хотя бы по той причине, что я его напишу раз и он будет > > работать всегда для данной версии протокола. > > С текстом же, застрелившись, и написав (или не застрелившись и взяв > > готовый) парсер, я даже не узнаю когда в принципе построения заголовков > > что-то изменится. > > > > Кстати, какая это версия протокола, где посмотреть формат, чтоб написать > > парсер? > > Допустим, есть задача сделать формат хранения почты так, чтобы каждый > > элемент заголовка (каждый Received: и т.п. раскладывался на составляющие) > > хранился отдельно, индексировался, и по нему можно было производить поиск. > > Может есть готовые парсеры, способные раскладывать всё, что используется в > > SMTP/mbox на мельчайшие детали? > > > Почему это вдруг бинарный формат -- это монолит на века, а текстовый > может меняться, как ему вздумается и без всякого предупреждения? От > меня смысл такой связи совершенно ускользает. > > Что до сложности формата mbox по сравнению с бинарными, звучит, > признаться, даже смешно. Когда мне нужно было выдернуть несколько > полей из большого количества писем и что-то с ними сделать, я решил > всю задачу на sh+coreutils+grep быстрее, чем в описании бинарного > формата нашёл бы и прочитал спецификации на эти поля и функции их > выдёргивания.
Для одноразового решения хороший вариант. Но, для больших объёмов не подходит, индексировать некак. Читай выше со слов "Допустим, есть задача..." -- Покотиленко Костик <[email protected]> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
