Доброго времени!

Есть проект. своего рода сервер нотификации. Эксплуатируем успешно 5 лет. Но вот при каждом нововведении(а их накопилось много: крипто, смс, е-майл и т.д. и т.п.) приходится влезать исходники и добавлять свое. Год назад посмотрел в сторону реализации плагинов(отделить базовую часть от наработок). Вроде получилось. Но все свелось к единому интерфейсу плагинов.
сейчас пытаюсь как то уйти от единого интерфейса. вообщем опишу по пунктно.
1. на клиентской части запрашивается какие ф-ции плагин экспортирует.
2. ну и там же составляется схема обработки сообщения.
3. на серверной стороне согласно полученным схемам производится обработка. допустим:
пришло сообщение -> расшифровать(плагин крипто) -> проверить ЭЦП(плагин крипто) -> отправить СМС(плагин е-майл)
4. так вот сейчас пришел к тому что нету единообразия в плагинах(кол-во входящих/исходящих данных, некоторым вообще надо передавать callback-функцию основной проги как парамметр и т.д.)
5. как быть? может кто то реализовывал подобной? т.е. хотелось бы уйти от правки основной проги как, и грубо говоря рисовать схему прохождения документов как своего рода взаимодействие плагинов.

Здравствуйте, Аноним, Вы писали:

А>Доброго времени!

А>5. как быть? может кто то реализовывал подобной? т.е. хотелось бы уйти от правки основной проги как, и грубо говоря рисовать схему прохождения документов как своего рода взаимодействие плагинов.
Хмм... Немного сумбурно, но... можно попробовать сдлаеть так.
В плагины вынести транспорт и какие-то действия вроде проверки ЭЦП, теста на спам и т.п. а логику обработки писать на скриптовом языке типа Пиотона. Единственное, что нужно сделать нормальный формат хранения данных (например xml или jason), который будет использоваться во всех плагинах. Либо вообще многие вещи увести в скрипты, а как плагины оставить только транспорт.

Здравствуйте, Аноним, Вы писали:

А>Доброго времени!

А>5. как быть? может кто то реализовывал подобной? т.е. хотелось бы уйти от правки основной проги как, и грубо говоря рисовать схему прохождения документов как своего рода взаимодействие плагинов.

в одном проекте по обработке большого объема разнородных данных (и в зависимости от типа данных их нужно было по разно му процессить по оч не простым правилам бизнес логики) было сделано так:
0) хренова туча плагинов экспортила фигову тучу разных (элементарных и не оч) функций
1) в XML было описание того что и как нужно процессить
1.1) базовый набор тэгов XMLя содержал некие control tagи (if, call, что-то еще)
1.2) функции из плагинов мапились в некие тэги в основную XML и принимали какие-то параметры через атрибуты. что-то "хардкодилось" в этом XML, что-то имело спец назначение (чтобы можно было принимать обрабатываемые данные и куда-то передавать результат дальше)

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

Здравствуйте, Kernan, Вы писали:

K>Хмм... Немного сумбурно, но... можно попробовать сдлаеть так.
K>В плагины вынести транспорт и какие-то действия вроде проверки ЭЦП, теста на спам и т.п. а логику обработки писать на скриптовом языке типа Пиотона. Единственное, что нужно сделать нормальный формат хранения данных (например xml или jason), который будет использоваться во всех плагинах. Либо вообще многие вещи увести в скрипты, а как плагины оставить только транспорт.

Честно не хотелось использовать скриптовый язык. В принципе сейчас пытаюсь написать что то вроде рисовалки логики. Вот тут то и натолкнулся на грабли не возможности "причесывания" всех плагинов к единому интерфейсу. Всю логику храню в json формате. Серверная часть парсит конфиг "задачи" и дергает плагины. Реализован свой "интерпретатор" (if, for и т.д.). Но все эт работает на "примитивах" с единообразным интерфейсом плагина(in/out параметр). вообще как хотелось бы — в рисовалке "вставляю" плагин "захожу"(по правой клавише мыше) в его свойства выбираю экспортированную ф-цию, сразу в форме свойств скажем в списке выводятся параметры ф-ции, далее я допустим "притягиваю" к этим параметрам какие то переменные(реализовано в среде) или же "натравливаю" ф-цию другого плагина....вот. все эт вроде реализовано но только с однородным интерфейсом плагина. Сейчас кстати начал писать плагин сетевой сервер, ну и захотелось, что бы входным параметром была callback ф-ция(вроде тоже реализовал)...но это ф-ция эта опять же из серверной части, а хотелось что бы допустим ф-ция другого плагина...

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Kernan, Вы писали:

K>>Хмм... Немного сумбурно, но... можно попробовать сдлаеть так.
K>>В плагины вынести транспорт и какие-то действия вроде проверки ЭЦП, теста на спам и т.п. а логику обработки писать на скриптовом языке типа Пиотона. Единственное, что нужно сделать нормальный формат хранения данных (например xml или jason), который будет использоваться во всех плагинах. Либо вообще многие вещи увести в скрипты, а как плагины оставить только транспорт.

А>Честно не хотелось использовать скриптовый язык. В принципе сейчас пытаюсь написать что то вроде рисовалки логики. Вот тут то и натолкнулся на грабли не возможности "причесывания" всех плагинов к единому интерфейсу. Всю логику храню в json формате. Серверная часть парсит конфиг "задачи" и дергает плагины. Реализован свой "интерпретатор" (if, for и т.д.). Но все эт работает на "примитивах" с единообразным интерфейсом плагина(in/out параметр).
Ты роешь себе могилу.
А>вообще как хотелось бы — в рисовалке "вставляю" плагин "захожу"(по правой клавише мыше) в его свойства выбираю экспортированную ф-цию, сразу в форме свойств скажем в списке выводятся параметры ф-ции, далее я допустим "притягиваю" к этим параметрам какие то переменные(реализовано в среде) или же "натравливаю" ф-цию другого плагина....вот. все эт вроде реализовано но только с однородным интерфейсом плагина. Сейчас кстати начал писать плагин сетевой сервер, ну и захотелось, что бы входным параметром была callback ф-ция(вроде тоже реализовал)...но это ф-ция эта опять же из серверной части, а хотелось что бы допустим ф-ция другого плагина...
Сперва научись создавать логику в просто текстовом файле, а потом просто сделай генерилку этоих файлов из графической тулзы.

Здравствуйте, Kernan, Вы писали:


А>>Честно не хотелось использовать скриптовый язык. В принципе сейчас пытаюсь написать что то вроде рисовалки логики. Вот тут то и натолкнулся на грабли не возможности "причесывания" всех плагинов к единому интерфейсу. Всю логику храню в json формате. Серверная часть парсит конфиг "задачи" и дергает плагины. Реализован свой "интерпретатор" (if, for и т.д.). Но все эт работает на "примитивах" с единообразным интерфейсом плагина(in/out параметр).
K>Ты роешь себе могилу.
Почему?

А>>вообще как хотелось бы — в рисовалке "вставляю" плагин "захожу"(по правой клавише мыше) в его свойства выбираю экспортированную ф-цию, сразу в форме свойств скажем в списке выводятся параметры ф-ции, далее я допустим "притягиваю" к этим параметрам какие то переменные(реализовано в среде) или же "натравливаю" ф-цию другого плагина....вот. все эт вроде реализовано но только с однородным интерфейсом плагина. Сейчас кстати начал писать плагин сетевой сервер, ну и захотелось, что бы входным параметром была callback ф-ция(вроде тоже реализовал)...но это ф-ция эта опять же из серверной части, а хотелось что бы допустим ф-ция другого плагина...
K>Сперва научись создавать логику в просто текстовом файле, а потом просто сделай генерилку этоих файлов из графической тулзы.
так вроде выше написал, что логику в тестовом формате сохраняю(json)