Re: Функционал и интерфейс
В Птн, 13/03/2009 в 21:49 +0300, Artem Chuprina пишет:
> Покотиленко Костик -> debian-russian@lists.debian.org @ Fri, 13 Mar 2009 19:56:06 +0200:
>
> >> >> >> Вот, навскидку назвал, и
> >> >> >> это несмотря на то, что вы привели список _консольных_ утилит в основном.
> >> >> >
> >> >> > Просто для информации: к любой консольной утилите (у которой есть stdin
> >> >> > и stdout) веб-морду можно приделать как два пальца об асфальт.
> >> >> >
> >> >> Осталось только узнать зачем.
> >>
> >> ПК> Вот-вот.
> >>
> >> ПК> Плохая практика: прога с CLI + фронтенд
> >> ПК> Хорошая практика: прога с CLI <-- либа --> прога с GUI
> >>
> >> То, что ты назвал плохой практикой - unix way, и тот факт, что эта
> >> практика - плохая, требует обоснования. Нет, я не утверждаю, что
> >> браузер - достаточно хороший гуй, а HTTP - достаточно хороший протокол,
> >> чтобы тыкать их во _все_ дырки... Фронтенд совершенно не обязательно
> >> должен работать по HTTP...
> >>
> >> Ну и да, по ходу дела ты, по сути, записал в "плохую практику"
> >> практически все клиент-серверные решения. Начиная с SMTP и HTTP :-)
>
> ПК> Не так. Не путай клиент-серверное решение и IPC с фронтендом :). Разница
> ПК> очевидна:
>
> ПК> 1. IPC: связь нескольких процессов в пределах одной машины
>
> ПК> 2. клиент-серверное решение: связь нескольких процессов работающих на
> ПК> разных машинах
>
> Это разделение уже изрядно условно. Так, во-первых, я хожу к
> IMAP-серверу своего ноутбука вне зависимости от того, на том же ноутбуке
> у меня гнус или на совершенно другой машине.
>
> Во-вторых, и к нему, и к заведомо удаленному IMAP'у основной почтовки я
> хожу ... правильно, по IPC. Этот IPC транслируется на удаленный хост
> посредством ssh, но и gnus, и imapd видят пайпы к локальному процессу.
> Точнее, emacs и imapd видят пайпы, а гнусу безразлично, пайп там или
> сокет, он видит вообще буфер.
>
> Я уж молчу про erlang (как язык) и прочие средства кластерной работы. У
> них, я извиняюсь, задача _заключается в_ том, чтобы не было разницы, на
> одной машине оно выполняется или на разных.
>
> Ну и да, еще можно вспомнить про системы виртуализации и отношение их с
> лицензиями на софт :-) А они даже у микрософта учитывают разницу между
> виртуальной и физической машиной.
Не могу не согласится. Чем более развиты становятся эти элементарные
способы взаимодействия, тем тоньше грань между ними.
Это если смотреть на вопрос "в принципе". А если подойти с мыслью о
оптимальности, производительности и безопасности то окажется, что одни
способы целесообразнее использовать для одного рода взаимодействия
(локальный IPC), другие для другого (удалённый).
Как тут любят цитировать: инструмент используемый не по назначению имеет
свойство превращаться в грабли.
Вообще хочу сразу оговориться:
- я не против скриптовых языков
- я не против текстовых протоколов
- я не против любых других универсальных методов
однако следует понимать, что:
- универсальных методов не бывает :). Для каждой задачи хорош свой
метод: ограничено время для написания функционала - используй скриптовый
язык, нужна производительность и компактность - используй язык более
низкого уровня.
- то же касается и других универсальных методов, например, трюки с IPC:
проброс пайпа на другую машину и т.п. Это хорошо, так как быстро, но
даже тут много нюансов, лично сталкивался.
- на счёт текстовых протоколов всё гораздо загадочнее для меня. Дело в
том, что протоколы отличаются от тех же скриптов тем, что
разрабатываются они, грубо, один раз, а используются везде и большим
количеством людей.
Преимущество текстового протокола только в том, что его более удобно
читать человеку, а недостатков гораздо больше. Читать бинарные данные и
парсить текст - это несоизмеримо разные процедуры в плане
производительности.
Можно даже сказать, что людям написавшим текстовый протокол всего лишь
не хватило сил написать два вида преобразований, потому как остальные
затраты соизмеримы:
- команды удобовоспроизводимые человеком -> бинарный протокол
- бинарный протокол -> удобочитаемый (и заметьте настраиваемый, а не
такой как есть) вывод
Пару слов о глюках связанных с пробросом ввода вывода через различные
туннели: дело в том, что в данном случае вовликаются дополнительные
буферы промежуточных (родительских) каналов связи, которыми тяжело
управлять. Пример:
$ progA | ssh user@host progB
progA записывает каманду в вывод, команда улетает мгновенно в буфер ssh,
в случае простого протокола, без подтверждения доставки progA будет
считать команду доставленной, хотя на самом деле это ещё не так. Кроме
того часто тяжело заставить команды приходить раздельными порциями.
> ПК> 3. фронтенд: использование функционала программы с одним интерфейсом в
> ПК> другой программе с другим интерфейсом посредством чего-либо, в том числе
> ПК> и IPC.
>
> ПК> Во вменяемых ресурсах по написанию программ так и написано: "функционал
> ПК> нужно отделять от интерфейса". Это для многих сложно, но на то есть свои
> ПК> причины, и от того есть много преимуществ.
>
> ПК> В проектах, где следуют такому принципу, фронтендами редко пахнет, так
> ПК> как если есть либа со всем функционалом, проще её и использовать, и не
> ПК> бояться, что в используемой программе ключики поменяются.
>
> ПК> Это моё личное мнение, кто не согласен, начинайте новую тему, интересно
> ПК> послушать что вам есть сказать.
>
> Тебе не приходило в голову, что у библиотеки вообще-то тоже есть
> интерфейс? Правда, рассчитанный на разработчика, а не на энд-юзера.
Как без него, API его зовут.
> Из чего, кстати, следует, что функционал от интерфейса отделить
> невозможно.
RJ11, RJ45, 220В и USB - тоже интерфейсы, но разные очень. Не путай CLI
и API.
> Потому что тогда не будет способа воспользоваться
> функционалом :-)
>
> Так вот, у классической юниксовой CLI-программы интерфейс рассчитан на
> юникс-юзера. Который ближе к разработчику, чем к энд-юзеру. И тем
> самым просто является таким же API, что и у библиотеки.
Ну нет же. Разные они, если подробно разобраться. Учитывая
вышесказанное, API - для низкоуровнего (производительного и компактного)
программирования, CLI - для юникс-юзера и скриптов (по быстрому на
коленке).
На пример, для сбора счётчиков правил iptables можно использовать
обёртку вокруг iptables -nvL | iptables-save типа:
iptables-save | grep "<условие>" | cut -d" " -fI
или такую конструкцию на Си:
...
struct ipt_entry *ipt_e;
char *target;
for(ipt_e=iptc_first_rule(chain_name, &ipt_h); ipt_e;
ipt_e=iptc_next_rule(ipt_e, &ipt_h)) {
if(!ipt_e) {
printf("iptc_first_rule(): returned NULL pointer\n");
return(NULL);
}
if(!<условие>) continue;
target=iptc_get_target(ipt_e, &ipt_h);
printf("Source IP: %s/%s (iface: %s), Destination IP: %s/%s (iface: %
s), Target: %s, Counters: %llu bytes, %llu packets\n",
x_strcpy(inet_ntoa(ipt_e->ip.src)),
x_strcpy(inet_ntoa(ipt_e->ip.smsk)),
ipt_e->ip.iniface,
x_strcpy(inet_ntoa(ipt_e->ip.dst)),
x_strcpy(inet_ntoa(ipt_e->ip.dmsk)),
ipt_e->ip.outiface,
target,
ipt_e->counters.bcnt,
ipt_e->counters.pcnt
);
}
...
Первый вариант делается за 5 минут, подойдёт для не частого сбора
небольшого числа счётчиков.
Второй вариант "страшный", пока первый раз не сделаешь. Подойдёт для
частого сбора сотен показаний.
Дальше, если скармливать нужные счётчики и выводить их за один проход -
можно обрабатывать теоретически неограниченное количество счётчиков за
проход без дополнительных расходов.
Дольше, если превратить этот код в демон, можно значительно сократить
расходы связанные с частым сбором.
> Только
> протокол, над которым построен этот интерфейс, более высокого уровня,
> чем у сишной библиотеки, и позволяет работать с ним непосредственно
> человеку.
Что не везде плюс ;)
> Но если этот человек может алгоритмизовать некоторый набор
> своих действий - он поручает его программе, и API для этого у него уже
> есть.
Да, но это тоже, что и бегать в чугунных сапогах.
--
Покотиленко Костик <casper@meteor.dp.ua>
Reply to: