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

[svp]

Масса простейших абстрактных интерфейсов освобождает от необходимости плодить ещё бОльшую массу конкретных частных случаев. Можно, конечно, заделать один интерфейс со стороны приложения, но тогда плакало гибкое постепенное расширение объёмов потенциально выносимого в плагины функционала.
Прошлый мой пост следует понимать ка пример стратегии применения интерфейсов. На самом деле описания методов получения тайлов должны лежать в соответствующих zmp-файлах, то есть строго говоря в плагинах-слоёв. Механизм хранения локальных тайлов тоже реализуется в плагине (встроенном в планету изначально или нет -- не важно). Плагины у нас, ведь, должны собираться в пакеты. Следовательно такая схема позволит, к примеру, сделать плагин-слой-пакет, внутри которого будет реализация доставания тайлов, скажем, из GE.

[vdemidov]

В плагин:
map_name
X\Y\Z
V
URL (опционально)

Из плагина:
:content_data
override_cache_path

Вот что ты это написал? Это ты описал загрузчик тайлов или хранилище?
Что такое map_name? Откуда возьмется V? Если плагин сохранит файл куда сам захочет то как его потом Планета найдет что бы прочитать?
Извини, но с внутренней логикой это не согласуется совсем. Проще написать новую прогу.

Теперь svp ну ты сам подумай что ты пишешь.

- интерфейс гео-точки.

Ну и куда и зачем его девать без всего остального. Плагин-гео-точка звучит бредово.

Постепенно расширяя, наследуюя и документируя интерфейсы можно не задумываться о типах плагинов. Просто у интерфейса плагина сделать несколько методов (инициализации, запуска, финализации), а в качестве параметра инициализации передавать интерфейс приложения, возвращающий через свойства или по запросу нужные интерфейсы. Вполне классическая схема.

Ну и кто их будет вызывать? И что они делать будут, в состоянии когда прога им пока ничего предоставить не может? Я же написал, что ни одного сервиса плагинам Планета пока не предоставляет.

ИМХО, совершенно неправильно, что zmp-файлы как-то логически будут чем-то иным нежели плагины.

Это абсолютно правильно. Просто, zmp- это кусок конфига, а не кода. То что там есть паскалевский скрипт ничего не меняет, это просто выдернутые наружу настройки.
И хранить их можно в очень разных контейнерах. Я планирую в будущем сделать самодостаточные контейнеры на базе SQLite или Беркли ДБ, которые будут объединять базу тайлов и инфу содержащуюся сейчас в zmp. Что бы можно было ту же историческую карту запхать в один контейнер и просто открывать его, а не морочить голову с отдельным zmp и отдельными тайлами.

Я исходники Планеты давно не листал, тяжело будет заставить её брать тайлы у соответствующего интерфейса, вместо нативной реализации загрузки? Может там всё так размазано по коду, что проще переписать, чем такой рефакторинг?

Ну год назад так оно и было. Сейчас несколько лучше, но все еще рано говорить о плагинах реализующих тайлохранилище.

[Parasite]

В плагин:
map_name
X\Y\Z
V
URL (опционально)

Из плагина:
:content_data
override_cache_path

Вот что ты это написал? Это ты описал загрузчик тайлов или хранилище?

Загрузчик, вестимо. С хранилищем еще проще - отдал в плагин хранилища контент и желаемое место записи (override_cache_path), дальше пускай плагин разбирается что с этим делать, и писать ли контент в жестко заданное место (согласно своей логике) либо в override_cache_path согласно пожеланий САСа\пользователя\загрузчика.

Таким образом например тайлы с контентом DG можно писать в нормальный чистый кэш, а ВНЕЗАПНО приходящие белые тайлы в нем же - кидать в null или в ./errors через override_cache_path, и в чистый кэш оно не пойдет и чистить потом не надо будет. А просканировав потом (ручками) ./errors - получаем список тайлов для перекачки, без необходимости перелопачивать весь многогигабайтный чистый кэш на предмет нескачанного.

Что такое map_name?

Имя карты.

Откуда возьмется V?

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

Если плагин сохранит файл куда сам захочет то как его потом Планета найдет что бы прочитать?

Спросить у текущего плагина-хранилища "Хочу контент тайла X\Y\Z\ версии V для карты XXXX". Плагин разберется, где оно у него - и выдаст контент или еррор.
Если плагин хранилища на этапе сохранения тайла поддерживал override_cache_path - то очевидно, что он должен поддерживать оное и при чтении с хранилища тоже. Как именно - зависит от плагина, разумеется.

[Parasite]

нормально нормально. очень даже конструктивный разговор.

Да лично мне-то без разницы, просто других более чувствительных хомяков распугаем. Их тут в этой ветке и так не сказать чтобы валом, так еще и ломание копий тут.

[vdemidov]

Да лично мне-то без разницы, просто других более чувствительных хомяков распугаем. Их тут в этой ветке и так не сказать чтобы валом, так еще и ломание копий тут.

Ну распуганных хомяков запишем в неизбежные потери Я надеюсь svp так просто не напугать.

А по описанию процесса в предыдущем посте - разве не очевидно?

Совершенно не очевидно после "override_cache_path". Какого хрена плагин отвечающий за скачивание должен командывать куда записывать?
Дальше.
Из плагина: content_data
А ты не думаешь, что все не так просто? Что плагин должен уметь сообщить планете, что тайла нет на сервере? или что уже забанили? или что сервер в дауне? Или что еще качалке скорее всего понадобиться передать настройки прокси? А еще тут регулярно вопросы, о том как проверить не обновился ли тайл на сервере, как прикажешь это делать с таким плагином. А еще от качалки нужно получить content type скачанного что бы знать как его открывать и нужно ли конвертить.
В общем с качалкой тайлов куча вопросов, я кончено хочу сдеать такой плагин, но пока еще код закачки тайла в Планете слишком размазан, что бы его выделять в плагин.

В общем с этим разобрались. Еще предложения?

[vdemidov]

Идем дальше.

Что такое map_name?

Имя карты.

Какое имя? Просто текстовое, так оно на разных языках может быть разным. Сейчас и в ближайшем будущем для идентификации используется GUID.

Откуда возьмется V?

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

Ну вот где хранить версию для тайла в SAS? Заводить под каждый тайл еще файлик с версией? или в имени файла, но если в имени, то как прикажешь потом этот файл находить, особенно учитывая то, что во многих сервисах текст номера версии весьма произвольный. Так что таки не будем об этом. Пока нет и в ближайшем будущем не будет.

[Parasite]

Совершенно не очевидно после "override_cache_path". Какого хрена плагин отвечающий за скачивание должен командывать куда записывать?

Такого, что ситуация "эти тайлы писать в основной кэш, а эти - вооон туда" - встречается сплошь и рядом. Например, можно сделать экспорт нужного выделения по карте в отдельную папку\на флешку СРАЗУ в процессе скачки, а не двумя операциями. Либо писать одновременно в ДВЕ локации - в кэш и на флешку. Или еще как...Короче, это НУЖНО.
См. аналоги в HC: hc.cache.path, hc.cache_file_name, re.replace (все три - R/W в в зоне действия плагина).
--------
if url:find('hl=ru-RU', 1, true) then
url = re.replace(url, [[/hl=]], '/dbRoot.v5/hl=') -- правило замены урла
local source = hc.cache_path .. hc.prepare_url(url) -- правило замены path
...
hc.cache_file_name = hc.prepare_url(url) -- пишем русские dbroot_GE тайлы в сторону от основного кэша
local file = io.open(hc.cache_file_name, 'w')
local file1 = io.open(source, 'w')
--------

А еще тут регулярно вопросы, о том как проверить не обновился ли тайл на сервере, как прикажешь это делать с таким плагином. А еще от качалки нужно получить content type скачанного что бы знать как его открывать и нужно ли конвертить.

Качалка будет _в этом же плагине_, для начала (позже, что более правильно - сделать плагин к сасу и на закачку тоже). Благо что встроенная сасовая качалка на наст.момент далека от совершенства (мультитреды например тут просят с самого основания, мультипрокси недавно просили, и тд).
Про content_type - разумеется, я же не все до единой плагинные поля перечислял. Я описал лишь общую идею, а конкретные списки параметров как раз и подлежат обсуждению и добавлению.
Например можно вычислять факт изменения тайла по хэшу, и передавать пунктик "а у нас уже есть точно такой же тайл в кэше, то есть мы не обновились!" в САС тоже... Да много чего можно. В том же HC тоже от версии к версии докидываются и расширяются возможности плагинов, при этом старые как работали так и работают (но ничего не мешает их обучить новым фичам, если охота - они скриптовые и открытые).

Какое имя? Просто текстовое, так оно на разных языках может быть разным.

Обычное имя. Можно заюзать уже употребимые - LAND, MAP, BOTH, GURTAM и проч по списку уже существующих zmp в сасе.
Зачем нужно? Затем, что на многих сервисах есть несколько карт, различающихся лишь парой символов в урле (а вся логика формирования урла - одинакова для всех). Пример - гугль. Нет смысла делать несколько плагинов на такие серверы - имхо достаточно сделать один (например GM.pl) и у него уже спрашивать имя нужного серввиса. Плагин разберется, построит нужный УРЛ, скачает и отдаст сасу контент.

Ну вот где хранить версию для тайла в SAS?

А щас-то она где хранится?
По уму бы, конечно, надо бы автодетект текущей версии....но это уж совсем уж задел на будущее.

во многих сервисах текст номера версии весьма произвольный.

В каком бы формате он ни был - в кэше он обязан присутствовать как один из идентификаторов каждого отдельного тайла. Это такой же параметр как Х\У.
PS: а в ГЕ еще и _время_ к.тайла есть, вдобавок к версии и координатам\зуму...

[vdemidov]

Такого, что ситуация "эти тайлы писать в основной кэш, а эти - вооон туда" - встречается сплошь и рядом. Например, можно сделать экспорт нужного выделения по карте в отдельную папку\на флешку СРАЗУ в процессе скачки, а не двумя операциями. Либо писать одновременно в ДВЕ локации - в кэш и на флешку. Или еще как...Короче, это НУЖНО.

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

Благо что встроенная сасовая качалка на наст.момент далека от совершенства (мультитреды например тут просят с самого основания, мультипрокси недавно просили, и тд).

Ну это таки так. Все руки никак не дойдут. Это будет один из ближайших типов плагинов, но как только более менее определюсь какой у него интерфейс должен быть.
И кстати, количество коннектов на сервер прекрасно задается в zmp и по-умолчанию равно 1 (MaxConnectToServerCount еще осенью прошлой появилось, и вроде как для DG использовалось). Тоесть если хочешь что бы качалось в несколько потоков с сервера нужно запускать несколько закачек и не забыть добавить колличество коннектов к серверу в zmp.

Ну вот где хранить версию для тайла в SAS?

А щас-то она где хранится?

Да нигде она не хранится. В принципе. Я говорю про версию скачанного тайла. А не про версию, которая идет в запрос.

В каком бы формате он ни был - в кэше он обязан присутствовать как один из идентификаторов каждого отдельного тайла. Это такой же параметр как Х\У.PS: а в ГЕ еще и _время_ к.тайла есть, вдобавок к версии и координатам\зуму...

От ГЕ никто не требует поддержки простого файлового кеша. А вот представь, что я завтра скажу что все. Никаких файловых кешей, только контейнер на Беркли ДБ. Сколько будет криков возмущения? В общем с версиями тайлов вопрос закрыт. Я их добавлять не собираюсь, feya тоже.

[Parasite]

Такого, что ситуация "эти тайлы писать в основной кэш, а эти - вооон туда" - встречается сплошь и рядом. Например, можно сделать экспорт нужного выделения по карте в отдельную папку\на флешку СРАЗУ в процессе скачки, а не двумя операциями. Либо писать одновременно в ДВЕ локации - в кэш и на флешку. Или еще как...Короче, это НУЖНО.

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

Та не вопрос. Лишь бы оно работало и делало что нужно.

Качалка будет _в этом же плагине_, для начала

Ты определись. Ты же говорил, что это и есть плагин-качалка.

Так я и щас то же самое сказал. Функция добывания тайла из инета будет в самом плагине (в каждом), а не внутри САСа где на нее практически никак влиять нельзя.
При этом появится возможность тонкой настройки процесса скачки в том же плагине и исключительно для данного сервиса (например где-то можно качать в сто потоков одновременно, где-то - только в один по очереди и с задержками, где-то - с хитрыми хидерами, где-то можно на лету тайлы кропать\ресайзить прежде чем в сас отдавать, и проч.)

Благо что встроенная сасовая качалка на наст.момент далека от совершенства (мультитреды например тут просят с самого основания, мультипрокси недавно просили, и тд).

Ну это таки так. Все руки никак не дойдут. Это будет один из ближайших типов плагинов, но как только более менее определюсь какой у него интерфейс должен быть.
И кстати, количество коннектов на сервер прекрасно задается в zmp и по-умолчанию равно 1 (MaxConnectToServerCount еще осенью прошлой появилось, и вроде как для DG использовалось). Тоесть если хочешь что бы качалось в несколько потоков с сервера нужно запускать несколько закачек и не забыть добавить колличество коннектов к серверу в zmp.

Не знал. Спасибо, воспользуюсь.

Ну вот где хранить версию для тайла в SAS?

А щас-то она где хранится?

Да нигде она не хранится. В принципе. Я говорю про версию скачанного тайла. А не про версию, которая идет в запрос.

Дак вот и я тебе про что? Теряется кусочек важной инфы. Безврзвратно и без возможности восстановления.
Для тайлового кэша ее хранить нужно в имени папки (.cache/<map_name>/<ver>/Xi/X/Yi/Y.jpg).
Для базовода - тем более очевидно что рядом с тайлом (пример - SatMap, там изначально версионность была).

[svp]

Теперь svp ну ты сам подумай что ты пишешь.

- интерфейс гео-точки.

Ну и куда и зачем его девать без всего остального. Плагин-гео-точка звучит бредово.

Я всегда думаю, что пишу. К тому же я нигде не писал про "Плагин-гео-точку". Интерфейс -- не есть плагин.
Большинство плагинов (не источники тайлов, и не тайлохранилища, и не им подобные) будут вызываться по инициативе пользователя и им не нужно передавать какие-то специфические данные. Данные контекста через интерфейсы приложения они могут получить сами.
Например, специфический плагин склейки: Пользователь жмёт кнопку или сочетание клавиш, на которые повешен запуск плагина. При этом приложение вызывает метод интерфейса плагина Start(App: IPluginApplication).
Плагин, первым делом пытается запросить необходимые ему интерфейсы: через App, например, ISASPlanet. Не получил -- exception; получил -- едем дальше. Берём ISASPlanet.CurrentSelection типа ISelection. Проверяем селекшн на пустоту и дальше по обстоятельствам. При необходимости можно запросить через ISelection, к примеру, IRectSelection или IPolySelection. Дальше плагин создаёт отдельный процесс, рисует немодальное окно с отражением процесса своей работы и по завершении закрывается.
То же самое с интерфейсом Гео-точки. Плагину может быть нужны текущие координаты, для, к примеру, геокодирования, чтобы поиск населённого пункта вёлся с учетом функции релевантности, зависящей от расстояния от текущей точки.
Наполнить ISASPlanet такими полями можно уже сейчас. Можно добавить туда методы перехода к заданным координатам, сдвига экрана на вектор, зума и т.д., что доступно через интерфейс уже сейчас.
Именно об этом я и говорил.

Постепенно расширяя, наследуюя и документируя интерфейсы можно не задумываться о типах плагинов. Просто у интерфейса плагина сделать несколько методов (инициализации, запуска, финализации), а в качестве параметра инициализации передавать интерфейс приложения, возвращающий через свойства или по запросу нужные интерфейсы. Вполне классическая схема.

Ну и кто их будет вызывать? И что они делать будут, в состоянии когда прога им пока ничего предоставить не может? Я же написал, что ни одного сервиса плагинам Планета пока не предоставляет.

Прога им предоставит свой интерфейс, который можно постепенно расширять. Интерфейсы могут наследоваться и включать в себя версию. Тогда обратная совместимость со старыми плагинами сохранится.
К примеру, решили мы добавить в тот же ISASPlanet новый метод управления переключением карт, или зуммом. Чтобы старые плагины не переделывать, можно создать ISASPlanet_v2, унаследованный от ISASPlanet, в котором и будут реализованы нужные вещи. Плагин, не получив от планеты нужного интерфейса, может грамотно показать эксепшн. Старые плагины будут запрашивать старые интерфейсы, новые -- новые. Со временем содержимое старых интерфейсов можно сливать в базовый класс, тогда уж очень старые плагины перестанут работать и их придётся перекомпилить с расчетом на интерфейсы новых версий.

ИМХО, совершенно неправильно, что zmp-файлы как-то логически будут чем-то иным нежели плагины.

Я планирую в будущем сделать самодостаточные контейнеры на базе SQLite или Беркли ДБ, которые будут объединять базу тайлов и инфу содержащуюся сейчас в zmp. Что бы можно было ту же историческую карту запхать в один контейнер и просто открывать его, а не морочить голову с отдельным zmp и отдельными тайлами.

Ну это, ИМХО, чересчур. Вот есть я и, скажем, паразит. У него контейнер с GM 200 гигов, а у меня 30. Обновился механизм защиты у гугла. Что делать? Как апдейтить наши настройки в контейнерах? Настройки отдельно, а котлеты отдельно. Случай, когда их желательно иметь вместе скорее частный.