Comments 30
Вы только что изобрели pipe'ы
Идея pipeline не нова, но почему-то обычно пайпы используют для фильтров, а не для плагинов.
Отнюдь не только для фильтров, а для общения между процессами в том числе.
Ээээмммм, а как pipe вас совсем не устраивают?
cmd1 > cmd2 > cmd3
cmd1 | cmd2
и т.д.
cat some_file | grep «pattern» | sort -u | cut -f 2 | wc -l
Именно «stdio-плагины» в вашей терминологии.
cmd1 > cmd2 > cmd3
cmd1 | cmd2
и т.д.
cat some_file | grep «pattern» | sort -u | cut -f 2 | wc -l
Именно «stdio-плагины» в вашей терминологии.
UFO just landed and posted this here
все новое — хорошо забытое старое, ArtemKulyabin!
Многие современные программы имею такой функционал. Насколько помню в Visual Studio можно настроить, чтоб исходники перед компиляцией прогонялись какой нибудь дополнительной программой (такой себе собственный препроцессинг). Сейчас я работаю под Mac OS и использую редактор Smultron — в нем есть много функций, реализованных через такие «плагины» — например сортировка строк, или преобразование документа в HTML
Во многих текстовых редакторах поддерживаются такие «плагины», да что там долго думать — даже в Turbo Pascal 7 были такие «плагины» — они находились в меню Tools, оп умолчанию там был только Grep — поиск по папке проекта. К сожалению эта функция была слабо документирована и ей мало кто пользовался.
Да, еще и плагины к моей любимой системе мониторинга Munin работают по такому принципу! И их можно писать хоть на perl хоть на bash — на чем угодно
Я в юности лет десять назад писал под DOS девелоперский текстовый редактор (к сожалению, проект загнулся, и сорцы утеряны), который, в частности, мог запускать компилятор и разбирать его выхлоп, позиционируясь на ошибки. Только у всех компиляторов выхлоп в разном формате, а хотелось дать возможность юзеру добавлять произвольные компиляторы. Проблема решалась именно так: к любому компилятору пишется «плагин», который перепарсивает вывод компилятора, выдавая в фиксированном виде, понятном собственно редактору. Дальше в настройках редактора регистрируешь новый компилятор и «плагин» на определённые расширения файлов. Хочешь добавить новый компилятор? Пиши парсер за десять минут и подключай.
Тогда мне это казалось красивым решением, но не было никаких иллюзий, что я изобрёл что-то новое :-)
Тогда мне это казалось красивым решением, но не было никаких иллюзий, что я изобрёл что-то новое :-)
Многие тысячи проектов работают именно так.
Сотни из них перерастают этот этап и начинают писать собственный диспетчер шины (к которому все коннектятся и который эти самые сигналы роутит от поставщиков к потребителям).
Десятки доходят до dbus.
Сотни из них перерастают этот этап и начинают писать собственный диспетчер шины (к которому все коннектятся и который эти самые сигналы роутит от поставщиков к потребителям).
Десятки доходят до dbus.
Можете назвать хотя бы пару из этих многих тысяч проектов, которые использую пайпы для обмена данными с внешними программными модулями?
Диспетчеры системных сообщений — это отдельная тема.
Диспетчеры системных сообщений — это отдельная тема.
Вам интересно, чтобы это были именно Named PIPE?
Если нет — то, обычными текстовыми командами, являются, например, команды протокола HTTP.
Что касается удобства работы — то для Windows удобнее все-таки COM. Я делал в свое время один проект, в котором две части общались между собой через Named Pipe сериализованными данными, на создание протокола ушел месяц, в то время, как с помощью COM это можно было сделать за пару суток.
Если нет — то, обычными текстовыми командами, являются, например, команды протокола HTTP.
Что касается удобства работы — то для Windows удобнее все-таки COM. Я делал в свое время один проект, в котором две части общались между собой через Named Pipe сериализованными данными, на создание протокола ушел месяц, в то время, как с помощью COM это можно было сделать за пару суток.
Это может быть любой pipe или TCP сессия. Пайпы удобны своей простотой.
Хорошим примером является POP/SMTP, в HTTP все-таки немного другая логика.
В виндовсе есть еще старый добрый DDE, но это в виндовсе… Вариант со STDIO я реализовал за пару часов (из-за хитростей перенаправления STDIO в WinAPI), а первый плагин за несколько минут. Там вообще только элементарные printf()/scanf() используются.
Хорошим примером является POP/SMTP, в HTTP все-таки немного другая логика.
В виндовсе есть еще старый добрый DDE, но это в виндовсе… Вариант со STDIO я реализовал за пару часов (из-за хитростей перенаправления STDIO в WinAPI), а первый плагин за несколько минут. Там вообще только элементарные printf()/scanf() используются.
Все равно, канальный уровень — это полбеды, главная беда — протокольный уровень.
Тот же самый DCOM можно гонять через HTTP, а можно через пайпы. А можно и через stdio, если очень хочется, ведь это всего лишь канал.
И WCF можно гонять через что угодно, в том числе через stdio, если написать соответствующий класс.
Что в этом инновационного — в душе не знаю. В такой постановке вопроса на протокольном уровне придется решать задачи аутентификации, удержания сессии, ошибок при передаче данных и так далее.
Тот же самый DCOM можно гонять через HTTP, а можно через пайпы. А можно и через stdio, если очень хочется, ведь это всего лишь канал.
И WCF можно гонять через что угодно, в том числе через stdio, если написать соответствующий класс.
Что в этом инновационного — в душе не знаю. В такой постановке вопроса на протокольном уровне придется решать задачи аутентификации, удержания сессии, ошибок при передаче данных и так далее.
Зато мы получаем полную независимость от софта и железа, используемого на разных концах трубы. Важен только формат сообщений.
Что касается канала — это уже давно решенные вопросы. SSH+TCP (или VPN) дают безопасный канал без ошибок, а обрыв связи обработать не проблема.
Что касается канала — это уже давно решенные вопросы. SSH+TCP (или VPN) дают безопасный канал без ошибок, а обрыв связи обработать не проблема.
Это как?
Как наладить обмен по STDIO между компом и мобильником?
Там ниже канального уровня есть еще один, который как раз в железе реализуется.
Как наладить обмен по STDIO между компом и мобильником?
Там ниже канального уровня есть еще один, который как раз в железе реализуется.
Можно еще посмотреть в сторону .NET Remoting (один из подвидов — WCF), там по пайпам можно гонять запросы формата SOAP.
«dialog» и его многочисленные клоны (cdialog, gdialog, whiptail, zenity) активно используют не только stdin/stdout, а ещё и 3-4-5 — сколько потребуется каналов пайпов для общения с внешними подпрограммами / хуками / плагинами.
Плеер Audacious поддерживает input-плагины для парсинга и декодирования файлов через stdin/stdout.
Система управления ОС ALT Linux Alterator долгое время работала (да и сейчас, кажется, работает) на общении со своими модулями через stdin/stdout с кастомным протоколом под названием foo/woo внутри. Особенно советую посмотреть про модули на shell.
Практически любые wiki, статические обработчики шаблонов разметки и т.п., умеют подключать внешнюю обработку через какой-нибудь тэг типа
Основная рабочая оболочка компилятора gcc (которую все привыкли вызывать как /usr/bin/gcc) работает именно таким образом: она вызывает по очереди различные части комплекса GNU compiler collection (препроцессор, компилятор, линковщики и т.п.), общаясь с ними сама или соединяя их друг с другом через pipes.
В конце концов, наш Inquisitor построен целиком и полностью именно на модели взаимодействия модулей с основной запускалкой через stdin/stdout/stderr.
Все современные десктопные среды (KDE, Gnome, XFCE) имеют возможность работать через dbus (причём обычно не _системный_, как раз, а пользовательский — или по крайней мере в отдельном userspace).
Плеер Audacious поддерживает input-плагины для парсинга и декодирования файлов через stdin/stdout.
Система управления ОС ALT Linux Alterator долгое время работала (да и сейчас, кажется, работает) на общении со своими модулями через stdin/stdout с кастомным протоколом под названием foo/woo внутри. Особенно советую посмотреть про модули на shell.
Практически любые wiki, статические обработчики шаблонов разметки и т.п., умеют подключать внешнюю обработку через какой-нибудь тэг типа
%EXTERNAL(имя-программы, аргументы)%, который вызовет внешнюю программу и будет с ней общаться через stdin-stdout.Основная рабочая оболочка компилятора gcc (которую все привыкли вызывать как /usr/bin/gcc) работает именно таким образом: она вызывает по очереди различные части комплекса GNU compiler collection (препроцессор, компилятор, линковщики и т.п.), общаясь с ними сама или соединяя их друг с другом через pipes.
В конце концов, наш Inquisitor построен целиком и полностью именно на модели взаимодействия модулей с основной запускалкой через stdin/stdout/stderr.
Все современные десктопные среды (KDE, Gnome, XFCE) имеют возможность работать через dbus (причём обычно не _системный_, как раз, а пользовательский — или по крайней мере в отдельном userspace).
Огромное спасибо. Сам я по ключевым словам stdio plugin ничего толкового не нашел. Видимо, в линуксе это настолько обыденное дело, что его даже не упоминают.
Да не за что :)
Вообще, любое общение через pipes — будь то просто передать кусок данных в сыром виде или использовать какой-то протокол — это действительно такая штука, которой уже лет 30, если не 40. Все плюсы-минусы известны и понятны. Идеально для случаев, когда можно ограничиться каким-то простым взаимодействием.
Единственное, чем они всех обычно смущают — когда люди поначитаются всяких ужасов про DOS и VMS в духе «text mode vs binary mode для потока», про страшный символ Ctrl+Z который может случайно встретиться в бинарном потоке и всё вдруг испортить и т.п.
Вообще, любое общение через pipes — будь то просто передать кусок данных в сыром виде или использовать какой-то протокол — это действительно такая штука, которой уже лет 30, если не 40. Все плюсы-минусы известны и понятны. Идеально для случаев, когда можно ограничиться каким-то простым взаимодействием.
Единственное, чем они всех обычно смущают — когда люди поначитаются всяких ужасов про DOS и VMS в духе «text mode vs binary mode для потока», про страшный символ Ctrl+Z который может случайно встретиться в бинарном потоке и всё вдруг испортить и т.п.
Ну или даже вот самый банальный пример: если ввести такую команду и поискать все исполняемые бинарные файлы, которые можно вызвать, как отдельную команду в /usr/lib, но при этом эти исполняемые бинарные файлы не предназначены для запуска пользователем напрямую, на моей системе получается:
Если по приложениям — модули PolicyKit, хуки проверок rpm, методы dpkg build, модули gcc, модули openoffice, модули HAL, плагины к SCons, плагины к GIMP, плагины к GVFS, фильтры и растеризаторы cups, хелперы NetworkManager, модули evolution, бинарные модули emacs, плагины к byobu, плагины к postfix, etc, etc…
$ find /usr/lib -type f | xargs file | grep executable | wc -l 1519
Если по приложениям — модули PolicyKit, хуки проверок rpm, методы dpkg build, модули gcc, модули openoffice, модули HAL, плагины к SCons, плагины к GIMP, плагины к GVFS, фильтры и растеризаторы cups, хелперы NetworkManager, модули evolution, бинарные модули emacs, плагины к byobu, плагины к postfix, etc, etc…
OS Inferno и текстовый редактор Acme практически целиком базируются на этом подходе.
Sign up to leave a comment.
STDIO плагины или как совместить несовместимое