[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Как спастись от mysql-server в KDE 4.2



Покотиленко Костик пишет:
В Срд, 18/03/2009 в 13:52 +0200, Тихон Тарнавский пишет:
On Wed, 18.03.2009 11:16:03 , Покотиленко Костик wrote:
В Срд, 18/03/2009 в 10:22 +0600, Andrey Lyubimets пишет:
Покотиленко Костик пишет:
В Вто, 17/03/2009 в 18:25 +0300, Artem Chuprina пишет:
Покотиленко Костик -> debian-russian@lists.debian.org  @ Tue, 17 Mar
2009 17:02:39 +0200:

И что же парсит и преобразует telnet при работе в качестве
клиента SMTP?
ПК> Он то ничего не парсит, пользователя telnet'а приходится
парсить.

Ты опять все понимаешь с точностью до наоборот.  Пользователь
telnet _имеет возможность_ провести диалог с сервером, не будучи
_вынужден_ для этого пользоваться специальным инструментом.
Который с шансами будет малость, а то и немалость, устаревшим, и
поддерживать не все особенности протокола.

Приведу в пример, скажем, swaks - отладчик для конфигурации
SMTP.  У которого мне, помнится, не удалось найти средства
прервать диалог после команды DATA, но до вкармливания в сервер
собственно письма.

Так-то он весь из себя хороший, и пользоваться им для
тестирования конструкции со STARTTLS куда удобнее, чем руками...
Но вот пары нужных фич не умеет - и до свидания.  И что б я
делал, будь там бинарный протокол?  Разбирался бы в его коде,
чтобы туда эту возможность дописать?  А если бы он при этом еще
и был написан с использованием сишной библиотеки реализации
протокола, и этой возможности не было бы в _ее_ интерфейсе?
ПК> Это вопрос дисциплины. Бинарь к ней, кстати, располагает все
сравнения с ПК> текстом.

Последнее предложение на русский переведи, пожалуйста.

Впрочем, если ты так же пишешь и код, то можешь не переводить.
ПК> сорьки.

ПК> -все+вне

Ага. Опять-таки, совершенно не согласен. Да, располагает. Но не к той, которая нужна, а к той, где "за деревьями леса не видно".
Заголовки этого письма составляют: 5189 байт Текст этого письма с
подписями: 2104 байт КПД: 2104/(5189+2104)=~29%
Ты не тот КПД считаешь! нужно считать КПД читателя, заголовки пишутся в первую очередь для человека!
Письмо, я бы сказал, среднего размера.

При мысли о том что мне придётся написать парсер заголовков мне никакой
бинарь не страшен, хотя бы по той причине, что я его напишу раз и он будет
работать всегда для данной версии протокола.
И для данной версии твоей программы!
Логично, программы реализует протокол, или несколько. Зато это железно,
без нюансов. Как по мне, так неожиданно получать неожиданные данные не
лучше.

И ещё раз попрошу прояснить ускользающую от меня связь между
тукстовостью/бинарностью протокола или формата и степенью ожидаемости
данных, хранимых в этом формате или получаемых по этому протоколу.

Постараюсь на пальцах. Грубо говоря, если в тебе надо что-то добавить в
бинарном протоколе, с чётко определённым форматом, ты не сможешь это
сделать не скорректировав его клиентов и серверов, а точнее либу,
которую они используют, так, чтобы ничего не сломалось. Поэтому, к
вопросу придётся подойти системно.

В случае с текстовым протоколом, где всё не так чётко определено, ты
обломаешься и вставишь новое поле куда-нибудь, где оно не сильно
помешает, назавёшь его новой фишкой и никому не скажешь.

Тут баланс такой - либо делаешь всё как надо, либо потом разгребаешь
глюки и усложняешь парсеры.


Всё написано правильно, только в случае с текстовым протоколом, клиенты будут продолжать и дальше работать, в случае с бинарным - надо всех и сразу обновить, что зачастую невозможно.


Reply to: