vdemidov писал(а):я предполагал, что если захочу сделать ассинхронность вызова, то это будет задача вызывающей программы создать тред и дождаться ответа
Создать тред - да, однозначно, если плагину нужен поток (не только для старта, но и вообще если вдруг понадобится), он должен сам прямо запросить его у хоста, причём получить его остановленным, и для запуска потока опять же обращаться к хосту. То же касается любых выделений памяти. То есть все диспетчеры должны быть в хосте. В том числе в хосте любое чтение любых системных настроек, переменных и т.п. (например, версия ОС), но не в плагинах. Формально это может быть отдельный специальный плагин, но остальным плагинам об этом догадываться не обязательно.
Ждать окончания потока на всяких евентах смысла нет никакого. Поток сам в состоянии за собой подчистить и грохнуть все свои объекты. В крайнем случае отдельный низкоприоритетный сборщик мусора легко сделает дело и сильно упрощает код, уменьшая "связывание". Как то мне проблему утечки памяти и скорости работы на множественных вызовах Create-Free в огромном проекте раз и навсегда удалось победить именно выделением объектов из пула и пометкой их как неиспользуемые + повторным использованием живых неиспользуемых + реализацией сборщика мусора.
Здесь же на всякий случай упомяну очевидный факт, что нельзя передавать между хостом и плагинами указатели на объекты, если эти объекты используются после такой передачи, при необходимости объект сериализуется (в частности, не целиком, а только необходимые параметры). Строки передаются как PChar (очевидно, убийство PChar может инициировать как создатель, так и хост, это по договорённости в соответствии с контрактом).
Ещё комментарии по прочтению:
1) никаких версий в exif быть не должно, смысла дублировать одно и то же в сотнях мегов файлов ровно ноль, не говоря уже о том, что вообще желательно внутрь тайлов не лезть немытыми руками.
2) никакого гуя в плагинах, даже настройки плагинов пусть будут скриптовыми и парсятся хостом, рисовать динамически интерфейс настроек чрезвычайно тривиально и пишется один раз и навсегда.
3) загрузчик, читалка и писалка - разные интерфейсы (контракты, но не плагины), но не надо бояться их объединения как огня в одном пакете, в конце концов плагин может поддерживать оба публичных интерфейса (кэша) чтения и записи (по сути - потомки TStream в общем виде), идея объединения функциональности в модули много где используется, даже системные службы там пишутся, а уж про компоненты и говорить нечего. В терминах Parasite это означает, что override_cache_path и V в общем случае совершенно никак не связаны (что однако не означает, что они не могут быть связаны в некоторых случаях).
4) Выделю отдельно из предыдущего как пример непонимания сути публичного контракта. В предложении "если это качалка, то она может только отдавать тайлы или сообщать об ошибках" ошибка в лишем слове "только", его тут быть не должно. От хоста или плагина можно требовать реализации конкретной функциональности, но нельзя требовать отсутствие какой-либо другой функциональности (исключая маразм типа требования отсутствия AV и GPF-ов, а также не вызывать int 19h). Что там ещё реализует плагин - это половое горе его автора, и все шишки в случае чего полетят в него, но если заявленный контракт выполнен - взятки гладки.
5) публичный контракт (интерфейс в общем смысле) не должен меняться, сами потом запутаетесь, если надо изменения - публикуется новая версия (все разговоры о совпадении гуидов плагинов и пакетов здесь верные, сответственно, можно будет обновлять плагины независимо от саспланеты, а не обязательно синхронно), соответствено говорить об изменениях мажорной версии при изменении интерфейса нельзя, можно говорить о изменении мажорной версии при добавлении нового интерфейса, минорной - при прочих правках.
6) паскальскрипта за глаза хватит (перл я знаю хорошо, и как просто на нём пишется обработка текста тоже хорошо знаю, но не менее хорошо знаю тот факт, что самое сложное - не писать плагины, а подготовить хост для плагинов), но в идеале часто вызываемые плагины (не в смысле "каждый день пару раз", а, например, "один раз при скачке одного тайла") должны быть полностью бинарные и параметрически программируемые, иначе скорость работы просядет и всё равно потом придётся переписать на дельфу.
7) плагин не должен требовать какую-то минимальную версию программы. С точки зрения исполнения публичного контракта плагин и хост полностью равносильны, за исключением того, что хост может перестать поддерживать некоторые интерфейсы (в том числе временно). Соответственно плагин также точно нюхает интерфейсы хоста (например, если при (ре)инициалиации ссылка заполнена NULL-ом, плагин не может требовать этот интерфейс от хоста, если отсутствует критичный для работы интерфейс - соответствующая реакция), именно версия хоста не нужна, никакого смысла это не имеет, ибо никакой информации она (версия) не несёт.
8) "Если в нескольких пакетах есть плагины с одинаковым GUID, то используется первый загруженный" - категорически нельзя это делать, нужно тупо ругаться. Особенно если плагины начнут писать все кому не лень. Если имелось в виду "если гуиды пакетов этих плагинов совпадают" - так и надо было писать, неявно такие вещи подразумевать нельзя.
9) "Каждый плагин принадлежит к какому-то типу плагинов" - такая категоричная формулировка приведёт к бессмысленному увеличению количества категорий плагинов (ну или что равносильно по смыслу все "нестандартные" плагины будут в категории "нестандартные"). Кроме того плясать надо не от категорий плагинов, а от интерфейсов, которых один плагин может реализовывать множество. В этом смысле понятие категории плагина бессмысленное и лишнее, по нему очевидно плачет Бритва Оккама.
10) Необходимо дать возможность плагину конкретно указать, что он перекрывает (отключает) конкретный плагин или наоборот требует конкретный плагин. По гуиду. Разработчик плагинов сам знает свои гуиды, чужие в общем случае не знает (плагин пользуется только публичным контрактом хоста). Если придётся один пакет делить на 2 или наоборот объединить, невозможно будет соблюсти правильное дефолтное перекрытие пакета пакетом более высокой версии. Соответственно этому диспетчер плагинов пробует загрузить плагины начиная с максимальной версии и проверяя связи, в случае ошибок выгружая плагин и пробуя следующую версию.
>Функция добывания тайла из инета будет в самом плагине (в каждом),
Это несерьёзно. Как минимум необходимо уметь реализовывать плагинами цепочку фильтров параметров запроса и ответа http.
>Само понятие типа плагина вырождается, собственно в название (или GUID) интерфейса
Ни в коем случае. Плагин может для работы требовать одну кучу интерфейсов и предоставлять другую кучу.
>совершенно неправильно, что zmp-файлы как-то логически будут чем-то иным нежели плагины. Это те же плагины, просто кода в них нет
Это не плагины. Это возможная рыба для создания настроек плагинов (кэша, скачки и прочих). Не больше.
>ситуация "эти тайлы писать в основной кэш, а эти - вооон туда" - встречается сплошь и рядом
это да, верно, я б например зумы выше 16-го в общий кэш не клал бы, если б была такая возможность.
>плагин геокодирования получает не только текст, а и координаты центра экрана
Плагин (любой) не должен "получать" координаты центра экрана, он должен их сам просить при необходимости. Это общее правило работы с плагинами, если конечно не захочется потом взаимодействие хоста с плагинами переписывать. Параметрами передаётся только то, что определяет контекст и не может быть запрошено у хоста самостоятельно.
>вычислять расстояние плагину придется уже самому, так как интерфейс конвертера, который это умеет я пока публиковать не готов
1. Совершенно непонятно, что мешает опубликовать (дать на него ссылку при инициализации плагина или дать "пустой" интерфейс для запроса новых интерфейсов) публичный интерфейс хоста с функцией вида get_distance_between(point1, point2): double, чтобы эту функцию можно было б вызвать из плагина.
2. Суть правильной реализации взаимодействия плагинов и хоста в том, что если эта функция хоста недоступна, то плагин поиска по прежнему может искать и переходить на нужную координату, недоступен только "order by". В этом смысле этот пример весьма показательный, изначально требуется минимум и ограничений при отсутствии чего-либо тоже минимум.
>жду идей для новых типов плагинов
1. таким подходом плагины буквально демонизируются в глазах пользователей, разработчиков ПО тут полторы штуки, с многолетним опытом и того меньше, с опытом работы с плагинами совсем кот наплакал, и даже разумные идеи часто пресекаются на корню или доводятся до абсурда. Надо начинать с простых кирпичиков, которые в любом случае будут используемы в будущем и которые понятны простым смертным. То есть для начала необходимо реализовать примитивы типа чтения и установки текущей координаты, изменения зума и т.п.Реализовать настройку параметров плагинов, реализовать плагин сохранения параметров плагинов (в реестр или инишку или ещё куда - общая настройка). Не надо бояться, что таблица интерфейсов и/или функций в интерфейсе будет из сотни вызовов, до 256 шевелиться будет быстро ))
2. идеи есть в багтреккере ))
3. Хороший пример плагина - полное исключение некоторых зумов для некоторых карт. Это новая функциональность (пока плагин не напишут, ничего не отъедет), а функциональность нужная и с точки зрения реализации плагина мегапростая (на входе в плагин - карта и зум, на выходе - признак разрешения или запрета, никаких данных с хоста плагин сам не попросит, проблемы с передачей параметров между разными версиями delphi нет никаких, в принципе сюда же потом можно перенести настройку доступности карты целиком и вообще). Но это больше работа в коде хоста, чем собственно реализация плагина.
4. Не надо гнаться выделять существующую функциональность в плагины просто ради самого выделения или тренировки плагинописания, в этом должен быть смысл (хотя бы даже повышение гибкости работы или настройки), иначе просто получится мертворожденный интерфейс. Например, в примере выше нет никакого смысла выделять get_distance_between в отдельный плагин.
