Какой язык мы должны использовать, чтобы позволить людям расширить нашу программу терминала / сниффера? - PullRequest
0 голосов
/ 20 августа 2010

У нас есть очень универсальное приложение для терминалов / анализаторов, которое может выполнять любые действия с TCP, UDP и последовательными соединениями.

Мы стремимся сделать его расширяемым - то есть позволить людям писать собственные парсеры протоколов, маркеры и т. Д.

Мы создали C-подобный язык для расширения продукта, а затем обнаружили, что для некоторых кодеров это представляет собой крутую кривую обучения.

Сейчас мы размышляем над вопросом: стоит ли нам придерживаться C или идти с чем-то вроде Ruby или Lua?

C прекрасно подходит для низкоуровневых вещей (например, для анализа двоичных данных), потому что он поддерживает указатели. Но именно по этой причине, это может быть трудно учиться.

Ruby (и т. Д.) Легки в изучении, но не имеют указателей, поэтому все, что связано с анализом двоичных данных, становится ужасно быстрым.

Что вы думаете? Для расширения продукта, который анализирует двоичные данные - Ruby / Lua или C / C ++?

Было бы замечательно, если бы вы могли дать некоторую предысторию, когда отвечаете, особенно если вы сделали что-то подобное.

Ответы [ 8 ]

4 голосов
/ 21 августа 2010

Wireshark , «ведущий в мире анализатор сетевых протоколов», также является анализатором / анализатором пакетов, ранее также называемым Ethereal.Он использует Lua, чтобы разрешить написание пользовательских диссекторов и нажатий, см. руководство .

Однако, обратите внимание, что я не использовал его, поэтому не могу сказать, насколько хорошо / эффективно / легко выучитьAPI есть.

2 голосов
/ 21 августа 2010

Как и TCL, Lua был разработан для тесной интеграции с приложением.Лично я считаю, что с синтаксисом и идиомами Lua гораздо проще работать, чем с TCL.

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

1 голос
/ 20 августа 2010

Ваше ядро ​​делает одну вещь очень хорошо, так хорошо. Пусть будет так. Я думаю, что вы должны создать API, основанный на std in / out, так же, как способ хорошего дизайна Unix. Тогда любой желающий может распространить его на любой язык по выбору.

1 голос
/ 20 августа 2010

Если у вас написан API, это имеет значение?Человек, использующий C-подобный API, должен понимать разницу между передачей по значению или ссылке.

0 голосов
/ 17 сентября 2010

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

Компания, в которой я работаю, разработала свой собственный язык. Он использует XML для структуры, поэтому анализ очень прост. Язык растет "по мере необходимости". Это означает, что если функция отсутствует, она будет добавлена. Я почти уверен, что он прошел путь от базы данных XML до чего-то, что требовало управления потоком. Но я хочу сказать, что если вы не думаете о том, чтобы создать его как язык, вы будете ограничивать то, что пользователи могут делать с ним непреднамеренно.

Лично я искал, как заставить компанию начать использовать Lua. И особенно Луа по нескольким причинам. Lua был разработан как дополнительный язык общего назначения. Он легко взаимодействует с языком, включая Python и Ruby. Это небольшой и простой для использования непрограммистами (не очень нужно в вашем случае). Достаточно просто заменить XML, INI ... для настроек конфигурации и достаточно мощно, чтобы заменить потребность в другом языке программирования.

http://www.lua.org/spe.html

0 голосов
/ 20 августа 2010

perl, sed, awk, lex, antler, ... Это языки, с которыми я несколько знаком, и на которых я хотел бы написать что-то вроде этого. Однако это зависит от потока данных.

Трудно сказать, что правильно использовать.Что-то, что я не думаю, что кто-то еще упомянул, это помнить, что в скриптах будут ошибки.Очень легко спроектировать что-то подобное таким образом, чтобы ошибки в сценариях (особенно ошибки времени выполнения) либо просто отображали «ошибку в сценарии», либо убивали всю систему.

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

0 голосов
/ 20 августа 2010

Я вторая идея Йохана.Хотя в прошлом, когда мне приходилось делать что-то подобное, я придерживался API-интерфейсов языка Си, и людям было запрещено использовать только язык Си.Но теперь, глядя на это, я понимаю, что было бы более эффективно, если бы мы сделали так, как Йохан описывает

PS: И по стечению обстоятельств это было приложение для тестирования протоколов с использованием анализатора пакетов

0 голосов
/ 20 августа 2010

Tcl был разработан с целью разрешить создание сценариев для программ на C, поэтому его будет гораздо проще реализовать.

...