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

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



В Срд, 18/03/2009 в 22:30 +0900, Alexander Danilov пишет:
> Покотиленко Костик пишет:
> > В Срд, 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%
> >>>> Ты не тот КПД считаешь! нужно считать КПД читателя, заголовки пишутся в 
> >>>> первую очередь для человека!
> >>>>> Письмо, я бы сказал, среднего размера.
> >>>>>
> >>>>> При мысли о том что мне придётся написать парсер заголовков мне никакой
> >>>>> бинарь не страшен, хотя бы по той причине, что я его напишу раз и он будет
> >>>>> работать всегда для данной версии протокола.
> >>>> И для данной версии твоей программы!
> >>> Логично, программы реализует протокол, или несколько. Зато это железно,
> >>> без нюансов. Как по мне, так неожиданно получать неожиданные данные не
> >>> лучше.
> >>>
> >> И ещё раз попрошу прояснить ускользающую от меня связь между
> >> тукстовостью/бинарностью протокола или формата и степенью ожидаемости
> >> данных, хранимых в этом формате или получаемых по этому протоколу.
> > 
> > Постараюсь на пальцах. Грубо говоря, если в тебе надо что-то добавить в
> > бинарном протоколе, с чётко определённым форматом, ты не сможешь это
> > сделать не скорректировав его клиентов и серверов, а точнее либу,
> > которую они используют, так, чтобы ничего не сломалось. Поэтому, к
> > вопросу придётся подойти системно.
> > 
> > В случае с текстовым протоколом, где всё не так чётко определено, ты
> > обломаешься и вставишь новое поле куда-нибудь, где оно не сильно
> > помешает, назавёшь его новой фишкой и никому не скажешь.
> > 
> > Тут баланс такой - либо делаешь всё как надо, либо потом разгребаешь
> > глюки и усложняешь парсеры.
> > 
> 
> Всё написано правильно, только в случае с текстовым протоколом, клиенты будут продолжать и дальше 
> работать, в случае с бинарным - надо всех и сразу обновить, что зачастую невозможно.

В этих словах сама суть. Или ты переходишь шагами и знаешь на каком что,
или ты съезжаешь и тебе не к чему привязаться и получается бардак.

Обратную совместимость соблюдать конечно надо, тогда переход будет
безболезненный. Пример сервер уже умеет новую вервию протокола с
расширенным набором команд, а клиент нет, в протоколе должна быть
возможность это выяснить и сервер может общаться с клиентом на старой
версии. Также и клиент должен общаться с сервером набором комонд,
которые тот поддерживает. Со временем сильно старые версии можно
запрещать.

-- 
Покотиленко Костик <casper@meteor.dp.ua>


Reply to: