История изменений
Исправление
arturpub,
(текущая версия)
:
Но, увы, не любой язык можно скомпилировать в динамическую библиотеку
Не совсем понятен ход твоих мыслей. Если ты пишешь плагин на сишке или любом другом языке, умеющем в C ABI, то получаешь so-шку, которую потом грузишь через so = dlopen() и общаешься примерно так:
struct API {
int (*func1)(void);
double (*func2)(const char *s);
} api = { ... };
struct PluginAPI {
void *instance_data;
struct API *api;
void (*close)(struct PluginAPI *plugin);
void (*process_event)(struct PluginAPI *plugin, const char *event);
};
void *so = dlopen("/path/to/plugin.so", 0);
struct PluginAPI *plugin1 = dlsym(so, "plugin_new")(&api);
plugin1->process_event(plugin1, "event_name");
// ...
plugin1->close(plugin1);
dlclose(so);
Для некомпилируемых языков просто будет одна so-шка для всего языка, которая будет бриджить API в язык и обратно, экспортируя его символы в соответствии с как там принято. Точно также PluginAPI будет замаплен на функции в скрипте. Единственное внешнее отличие — придется передавать имя скрипта в plugin_new:
dlsym(so, "plugin_new")(&api, script_path);
можно ли как-то таки скомпоновать хотя бы питоньий код в динамическую библиотеку
Можно, но зачем? Хочешь обязать «одминов» статически компилировать питон вместе со скриптом на каждый скрипт? Пусть пишут свои settings.lua, proces1.pl и obrabotka_dannyx.py где-нибудь в /usr/local/share/<daemon_name>/scripts и все.
Реализовывать оба интерфейса возможности нет
Не вижу причин. Если ты сделаешь бридж в скриптовую среду, то кто-нибудь за вечер склепает на ней модуль с posix.popen и начнет юзать его как типо-cgi-прокси. Вот необходимости такой и правда нет.
Исходная версия
arturpub,
:
Но, увы, не любой язык можно скомпилировать в динамическую библиотеку
Не совсем понятен ход твоих мыслей. Если ты пишешь плагин на сишке или любом другом языке, умеющем в C ABI, то получаешь so-шку, которую потом грузишь через so = dlopen() и общаешься примерно так:
struct API {
int (*func1)(void);
double (*func2)(const char *s);
} api = { ... };
struct PluginAPI {
void *instance_data;
struct API *api;
void (*start)(struct PluginAPI *plugin);
void (*close)(struct PluginAPI *plugin);
void (*process_event)(struct PluginAPI *plugin, const char *event);
};
void *so = dlopen("/path/to/plugin.so", 0);
struct PluginAPI *plugin1 = dlsym(so, "plugin_new")(&api);
plugin1->process_event(plugin1, "event_name");
// ...
plugin1->close(plugin1);
dlclose(so);
Для некомпилируемых языков просто будет одна so-шка для всего языка, которая будет бриджить API в язык и обратно, экспортируя его символы в соответствии с как там принято. Точно также PluginAPI будет замаплен на функции в скрипте. Единственное внешнее отличие — придется передавать имя скрипта в plugin_new:
dlsym(so, "plugin_new")(&api, script_path);
можно ли как-то таки скомпоновать хотя бы питоньий код в динамическую библиотеку
Можно, но зачем? Хочешь обязать «одминов» статически компилировать питон вместе со скриптом на каждый скрипт? Пусть пишут свои settings.lua, proces1.pl и obrabotka_dannyx.py где-нибудь в /usr/local/share/<daemon_name>/scripts и все.
Реализовывать оба интерфейса возможности нет
Не вижу причин. Если ты сделаешь бридж в скриптовую среду, то кто-нибудь за вечер склепает на ней модуль с posix.popen и начнет юзать его как типо-cgi-прокси. Вот необходимости такой и правда нет.