LINUX.ORG.RU

История изменений

Исправление 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-прокси. Вот необходимости такой и правда нет.