SASGIS

Веб-картография и навигация

SAS.Wiki

Веб-картография и навигация

Инструменты пользователя

Инструменты сайта


pluginapi:общая_информация_о_pluginapi

Вот что вообще представляет из себя система с поддержкой плагинов:

Некоторая информация о интерфейсах, COM, DCOM вообще и в Delphi в частности

Попытаюсь сформулировать свои требования к инфраструктуре плагинов.

  1. Любой плагин берется из пакета плагинов.
  2. Пакет плагинов находится в файле (Тоесть сам пакет может состоять и из нескольких файлов, но главный один).
  3. Сейчас пакет плагинов это просто dll с расширением spp, но должна быть возможность легко добавить новые способы хранения плагинов, например с электронной подписью dll, скриптовые или еще какие-нибудь.
  4. Файл с пакетом не блокируется без необходимости (например, пока не понадобится плагин из пакета, не вызывается LoadLibrary) в надежде что пользователь не начнет удалять файлы при работающей программе, а если и начнет, то не будет удивляться потом ошибкам.
  5. Каждый пакет идентифицируется по GUID.
  6. У каждого пакета есть номер версии, при загрузке из пакетов с одинаковым GUID выбирается с наибольшей версией.
  7. Должна быть возможность добавления кеширования информации о пакетах плагинов между сеансами работы программы.
  8. Должна быть возможность блокирования пакетов и отдельных плагинов по разным признакам, в том числе по черным и белым спискам.
  9. Каждый плагин идентифицируется по GUID.
  10. Если в нескольких пакетах есть плагины с одинаковым GUID, то используется первый загруженный.
  11. Каждый плагин принадлежит к какому-то типу плагинов.
  12. По сути тип плагина определяет публичный контракт, который плагин должен выполнять. В простейшем случае поддерживать определенный интерфейс.
  13. В программе должны легко добавляться новые типы плагинов.

PS: Не путаем отдельные плагины и пакеты плагинов. У каждого плагина свой GUID, и у пакета в который они входят тоже есть свой уникальный GUID.

PPS: Опять же, не путаем плагины и пакеты плагинов. Информация о версии есть только у пакета плагинов. Тобишь если разработчик обновил какой-то пакет плагинов и поменял ему имя файла, то загрузится по-любому самый новый, даже если старый удалить забыли. А вот 10-й пункт это уже нарушение, но тоже можно представить ситуацию - в новой версии пакет плагинов разделили на 2 или наоборот объединили два пакета, но этого стоит избегать всеми силами.

PPPS: А сейчас объясню почему я выбрал вариант, что в dll может быть много плагинов, а не ровно 1 штука. Просто в моем понимании каждый конкретный тип плагина задает очень жесткие рамки и требования для реализующих его, но разных типов я планирую наделать очень много. Поэтому вполне может получится, что какой-то механизм сможет реализовывать 3-4 типа плагинов используя общие 90% кода. Тогда разносить их в отдельные длл получается ну уж очень нерентабельно. Да и ресурсоемко держать столько открытых dll.

Перевод этой страницы: