Ищу желающих помочь с разработкой плагинов.

[vdemidov]

если ssp это плагин то у мну получилось собрать тестовый из примера.нужна будет рабочая планета для стимуляции.

Ну пока что, как я уже писал, инфраструктура плагинного движка живет отдельно от Планеты. И пока я ее до ума не доведу в Планете не появится. Но ты мог заметить, что я ее сейчас активно ковыряю, так что шансы есть.

[svp]

Йоштыть! А дело то движется!
Надо бы мой конвертер тайловый на плагины переписать. Тайловый енумератор через интерфейсы работает уже?

[vdemidov]

Надо бы мой конвертер тайловый на плагины переписать.

Разогнался. Мог бы и помочь чем-нибудь. Доступ к репозиторию где я плагинный движок ковыряю у тебя есть.
Вот что представляет из себя обобщенная система с поддержкой плагинов:

Так вот. Уже более менее есть "Plug-In Interface", и заканчиваю делать относительно приличный "Plug-In Manager". Но вот "Services", которые могут понадобиться плагинам, в частности енумератор тайлов, отстуствуют. Поэтому на ближайшее будущее принимаются к рассмотрению только те типы плагинов, которым не нужно от программы никаких Сервисов и сложного GUI. Хорошим примером такого типа плагинов мне показался сервис геокодирования, поэтому я его и предложил на всеобщее рассмотрение.

[vdemidov]

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

Вот что-то такое я и пытаюсь сделать. Если есть вопросы, предложения или замечания пишите.

[garl]

та вроде всё логично и демократично.
по ходу действий будем потихоньку пилить и дорабатывать.

[Parasite]

должна быть возможность легко добавить новые способы хранения плагинов, например с электронной подписью dll, скриптовые или еще какие-нибудь.
Если есть вопросы, предложения или замечания пишите.

А со с голым Перлом в сюды как-нибудь присоседиться - реально?

[vdemidov]

А со с голым Перлом в сюды как-нибудь присоседиться - реально?

Ну если ты или кто-то другой сделает соответствующий загрузчик для перловых плагинов, написанный на делфе, то милости просим. А еще, вероятно, плагинам на перле, понадобится какой-то адаптер для использования сервисов программы в прловом скрипте. Как оно реализуется ХЗ. Ну или ограничиваться типами плагинов, которые ничего от базовой программы не получают.
Я в ближайшие годы этим заниматся не собираюсь.

[VJean]

5. Каждый пакет идентифицируется по GUID.
9. Каждый плагин идентифицируется по GUID.

дважды?

6. У каждого пакета есть номер версии, при загрузке из пакетов с одинаковым GUID выбирается с наибольшей версией.
10. Если в нескольких пакетах есть плагины с одинаковым GUID, то используется первый загруженный.

что-то я запутался

[svp]

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

Да. Кроме кода в пакетах можно, ведь, хранить и некоторые ресурс, например, kml, или подложки какие-то.

[vdemidov]

5. Каждый пакет идентифицируется по GUID.
9. Каждый плагин идентифицируется по GUID.

дважды?

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

6. У каждого пакета есть номер версии, при загрузке из пакетов с одинаковым GUID выбирается с наибольшей версией.
10. Если в нескольких пакетах есть плагины с одинаковым GUID, то используется первый загруженный.

что-то я запутался

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