Конфиги и данные в виде исполняемого кода

danilov

Пусть есть приложение, у него имеются конфигурационные данные и данные приложения (все, кроме бинарных).
Допустим
1. Язык позволяет держать данные одновременно и human-readable и исполняемыми. То есть они преставляют собой код, написанный на языке.
2. Нет больших оверхедов на сборку проекта в таком виде.
Какие минусы есть такого подхода? Интерес исключительно праздный, Java для этого слишком непригодна. Встречал подобное в ruby-приложении, показалось интересным. Пока видится затруднённость (невозможность) горячей подгрузки. Но эта проблема есть и при разделённом подходе.

6yrop

я всеми руками за :D
Поломать можно больше, чем через обычные конфиги.
Пока видится затруднённость (невозможность) горячей подгрузки.
а в чем проблема?

danilov

> а в чем проблема?
Зависит от языка, если он позволяет это сделать безболезненно, то проблемы нет.

6yrop

Зависит от языка, если он позволяет это сделать безболезненно, то проблемы нет.
в java в чем проблема?

FRider

в питоне такое видел :D Отличная тема

danilov

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

vall

на SHell так и делают всегда

6yrop

Невыполнены оба пункта из допущений.
И если в случае конфигов с этим можно жить, то в случае данных уже нет, ибо их существенно больше (оверхеды на сборку и правятся другими людьми (не программистами).
неужто в java нельзя динамически компилировать код, в .NET это делается через Emit
погугли на тему java dynamically compilation code
вот тут меняют текстовый файл с кодом, и приложение его подхватывает, по-моему, как раз то, что тебе хочется
http://www.javaworld.com/javaworld/jw-06-2006/jw-0612-dynami...

danilov

Пункты-то не про это.
Можно динамически, да. Но вот полная сборка проекта существенно дольше и пропорциональна кол-ву данных (а их много, обычно сильно больше, чем кода).
И читаемость у java-кода не ахти для непосвещённого. А надо еще и писать, не только читать.

Werdna

Какие минусы есть такого подхода?
Как и у любой дырки, позволяющей выполнить левый код.

Maurog

Встречал подобное в ruby-приложении, показалось интересным.
что именно видели? дайте ссылочку\ключевые слова, пожалуйста, потому что не очень ясно о чем речь.
если речь о встраивании скриптового языка в приложение, то таким образом не каждый ресурс\данные можно запихать, да и проблемы с предоставлением песочницы могут быть, и не ясно какие возможности\ограничения накладывает такой метод определения входных данных, т.к. язык общего назначения

val63

У меня на одной из работ так однажды сделали.
Рассадник трудноуловимых багов, руки надо отрывать за такое по-хорошему:)

danilov

> Как и у любой дырки, позволяющей выполнить левый код.
Это следствие того, что почти забесплатно переносится часть логики исполнения в данные (что есть осознанный выбор разработчика
а защититься от исполнения левого кода достаточно легко единожды написанными проверками.

kill-still

вполне приемлемо, если допустим данные не очень секретные, но их надо спрятать от лишних глаз.
а вот конфиг - его же редактировать надо?

bleyman

Я считаю что в таком случае следует называть конфиг — лоадером, например, и относится к нему соответственно, и оформлять его соответственно. То есть не "приложение делает import custom_config", а "custom_run делает import application; application.configure("zzz" application.run".
Я к этому отношусь сугубо положительно, например. А вот к исполняемым конфигам — совершенно не так положительно.

Garryss

Совершенно нормально.
В скриптовых языках типа php такое используется повсеместно. А для bash'а так и вообще существует устоявшееся название "dot file" от команды ". my_config.sh".
Минусы/плюсы очевидны:
  • (-) В "конфиге" будет частично код — нужно тщательнее тестировать код в связке с "конфигом" при деплое
  • (-) Нужно следить за тем, чтобы девелоперы не начали в "конфиг" засовывать весь код
  • (-) Не-девелоперам будет сложнее править конфиг
  • (+) Не нужны парсеры и маппинг между конфигом в объекты

kill-still

ещё в плюсы можно записать то, что распространять приложение можно одним исполняемым файлом (и конфиг, и ресурсы - всё в одном) - порой очень удобно.
Оставить комментарий
Имя или ник:
Комментарий: