Покотиленко Костик - 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 (как язык) и прочие средства кластерной работы. У
них, я извиняюсь, задача _заключается в_ том, чтобы не было разницы, на
одной машине оно выполняется или на разных.
Ну и да, еще можно вспомнить про системы виртуализации и отношение их с
лицензиями на софт :-) А они даже у микрософта учитывают разницу между
виртуальной и физической машиной.
ПК 3. фронтенд: использование функционала программы с одним интерфейсом в
ПК другой программе с другим интерфейсом посредством чего-либо, в том числе
ПК и IPC.
ПК Во вменяемых ресурсах по написанию программ так и написано: функционал
ПК нужно отделять от интерфейса. Это для многих сложно, но на то есть свои
ПК причины, и от того есть много преимуществ.
ПК В проектах, где следуют такому принципу, фронтендами редко пахнет, так
ПК как если есть либа со всем функционалом, проще её и использовать, и не
ПК бояться, что в используемой программе ключики поменяются.
ПК Это моё личное мнение, кто не согласен, начинайте новую тему, интересно
ПК послушать что вам есть сказать.
Тебе не приходило в голову, что у библиотеки вообще-то тоже есть
интерфейс? Правда, рассчитанный на разработчика, а не на энд-юзера.
Из чего, кстати, следует, что функционал от интерфейса отделить
невозможно. Потому что тогда не будет способа воспользоваться
функционалом :-)
Так вот, у классической юниксовой CLI-программы интерфейс рассчитан на
юникс-юзера. Который ближе к разработчику, чем к энд-юзеру. И тем
самым просто является таким же API, что и у библиотеки. Только
протокол, над которым построен этот интерфейс, более высокого уровня,
чем у сишной библиотеки, и позволяет работать с ним непосредственно
человеку. Но если этот человек может алгоритмизовать некоторый набор
своих действий - он поручает его программе, и API для этого у него уже
есть. У тех разработчиков, которые об этом забыли (или забыли в букваре
про это прочесть), интерфейсы библиотек, кстати, тоже кривы до
умопомрачения. D-BUS тому ярким примером...
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: r...@jabber.ran.pp.ru
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
