Плагины из себя представляют внешние библиотеки (.dll для windows, .so для linux), которые ищутся при старте приложения в заранее заданной директории (например ./plugins), затем конфигурируются (выбираются те, которые следует загружать и выполнять), затем выбранные загружаются и выполняются. Так же должна быть возможностью последующего выключения и выгрузки плагинов (в специальном пункте меню). Плагины, как раз, и занимаются добавлением объектов в рендер для последующего их отображения.
Данные, которые должен содержать в себе плагин:
- Имя (может не совпадать с именем библиотеки)
- Тип (не обязательно; возможно для последующего разделения плагинов по функциональности)
- Автор (имя автора + контактная информация)
- Описание (чтобы знать, чего плагин делает)
- Версия плагина
- Требуемая версия рендера (не ниже)
6 комментариев:
Хм... тут же придумал минус такой схемы:
если вся инфа храниться о либе храниться в ней самой, то для того, чтобы её вытащить, либу нужно загрузить. Соответственно получается, что при старте приложения мы будем загружать все длл, хранящиеся в папке ./plugins. Но пока другого решения я не вижу.
IMHO лучше раскладывать плагины по папочкам, потому что они иогут содержать какие-нить доп файлы. конфиг хранить xml'кой или yaml'ом
Просто плагины писать будем не мы. Поэтому я думаю это сделать так, как это сделано в миранде =) Если будут доп файлы - пусть складывают в отдельную папочку, которая будет лежать рядом с плагином.
Небольшая дискуссия о системе плагинов:
(22:58:07) l1feh4ck3r: а ты мой ответ по поводу плугинов читал?
(22:59:43) dmitriy: что не вы их будете писать?
(22:59:55) l1feh4ck3r: ога. что сделать как у миранды =)
(22:59:57) dmitriy: я не думаю, что это проблема для хранения в папках =)
(23:00:23) dmitriy: ну ХЗ, наверное идея с плагином и папкой с тем же именем на том же уровне тоже неплоха =)
(23:01:09) l1feh4ck3r: да просто как там папка будет называться - уже не наши проблемы, ибо обращение к ней будет уже внутри плагина. да и данные там скорее всего будут получатся из БД.
(23:01:24) dmitriy: а вот тут ты не прав
(23:01:30) dmitriy: я бы стандартизировал и имя папок тоже
(23:01:44) dmitriy: ибо они могу их поназывать как угодно и потмо замучаешься разгребать где что
(23:03:31) l1feh4ck3r: а смысл? грубо говоря, про содержимое папки плугинс, кроме того, что там лежат библиотеки, мы ничего не знаем. да и помоему нам это знать не обязательно. уж какие там папки с какими именами - забота плагинописателей.
(23:04:43) dmitriy: как хочешь, но практика всех ЯП подсказывает, что лучше это стандартизировать
(23:05:09) dmitriy: вы пытаетесь в духе могучеф науки все так абстрагировать, что постарайтесь не сделать абстрактное говнище плиз =)
(23:05:13) dmitriy: *могучей
(23:05:33) dmitriy: да, вполне конкретное говнище тоже плохо ИМХО =)
(23:05:57) l1feh4ck3r: =))
(23:06:34) l1feh4ck3r: да мы просто над плагинами еще не очень думали. пока тока обсуждался рендер, даже об интерфейсах для плагинов еще ничего не было сказано.
(23:07:04) l1feh4ck3r: самая фишка ИМХО - стандартизировать интерфейсы для плагинов.
(23:07:54) dmitriy: это да, но и окружение тоже не сложно написать
(23:08:00) l1feh4ck3r: а насчет папок - все тот же пример миранда. там саму миранду, кроме дллек вообще ничего не заботит, чего там еще лежит в этой папке.
(23:08:16) dmitriy: можно вообще шаблончик плагина сделать и всем говорить, что надо в него код вписывать, а не с нуля собирать =)
(23:08:36) dmitriy: я уже понял, что у тебя главный аргумент миранда =)
(23:08:36) l1feh4ck3r: о. а вот это интересная мысль =)
Значицца так:
1. Плагины по папочкам раскладывать - идея не гуд, поскольку смысла нет. Если плагину надо хранить какие-то временные/настроечные etc файлы, то пусть он сам себе это и обеспечит.
2. При первой загрузке мы читаем все плагины и сохраняем о них информацию. При последующих будут загружаться только новые (которых нет в списках конфигурации) и необходимые (которые отмечены как необходимые для запуска). При этом проверяется соответствие версий.
3. Не очень хорошая идея требовать версию рендера. Лучше запрашивать список функциональных компонент рендера версии не ниже такой-то. Но это на обдумывание.
По первому пункту согласен.
Второй пункт тоже нравиться, чего-то мне в голову такое не пришло =)
А вот насчёт списка функциональности против версии рендера. Понятно, что есть вероятность того, что некоторая уже реализованная (мб с багами) функциональность будет выкинута, но, помоему, проще это отразить в чендж логе, чем придумывать способ отдавать информацию плагину о функциональности рендеру.
Отправить комментарий