svp писал(а):Мне видится идеальной система плагинов, применяемая в firefox и thunderbird.Можно как один плагин, так и несколько в пакете всегда хранить в zip-контейнере, как у того же файрфокса.Сам контейнер никогда не нужно блокировать, а плагины можно при установке просто распаковывать во внутренний рабочий каталог. Для portable версии (коих любителей здесь over 9к) этот каталог можно иметь внутри каталога с прогой, а для установленных Планет (или вообще любых хост-приложений, использующих эту плагинную систему) хранить в юзерском хомяке. В точичности как делает файрфокс. Зачем изобретать самокат (а-ля FAR с блекджеком), когда есть отличный кладезь мозиловских идей?
Ну оно бы хорошо, но кто это все будет реализовывать. Да и при моей схеме никто не запретит распространять плагины в виде неких инсталляционных пакетов в zip контейнере. К самому движку это имеет слабое отношение.
svp писал(а):Установленный плагин будет иметь свой гарантированно уникальный каталог в виде его же гуида. Плагины могут иногда иметь зависимости. Я не предлагаю реализовывать аналог дебиановского, к примеру, пакетного менеджера для отслеживания зависимостей, но чтобы избежать конфликтов можно просто предусмотреть в плагине специальный файл требований к среде, где перечислить допустимые вилки версий для всего окружения, что ему требуется. Ну и следовать правилам: меняется интерфейс -- меняем версию; меняется реализация -- меняем только субверсию.По всему выходит, что для пущей гибкости и, как ни парадоксально, простоты каждый плагин (или/и пакет?) должен всегда иметь в своей основе эдакий xml-файлик (xml потому, что структура легко расширяется с обратной совместимостью), где будет определяться основная техническая информация о плагине. О том, что он собой представляет (dll с реализацией некого интерфейса, или набор js-скриптов, как у мозиллы), о зависимостях от компонентов хост-приложения, о зависимостях от других плагинов, вилках совместимости с тем, отчего зависимости.
Ну сейчас у пакета плагинов предусмотрена выдача некоторого количества инфы о себе, своей версии и требуемой минимальной версии программы. Теоретически в любой момент можно заменить загрузчик плагинов, что бы он брал инфу не загружая саму dll, а из одноименного xml. Можно даже с проверкой хеша dll и даже электронной подписи и сертификата разработчика
А сейчас объясню почему я выбрал вариант, что в dll может быть много плагинов, а не ровно 1 штука. Просто в моем понимании каждый конкретный тип плагина задает очень жесткие рамки и требования для реализующих его, но разных типов я планирую наделать очень много. Поэтому вполне может получится, что какой-то механизм сможет реализовывать 3-4 типа плагинов используя общие 90% кода. Тогда разносить их в отдельные длл получается ну уж очень нерентабельно. Да и ресурсоемко держать столько открытых dll.
