Anonymous | Login | Signup for a new account | 21-11-24 13:20 UTC |
All Projects | SAS.Планета | Домен, сайт, форум, багтрекер | Доработка карты (ZMP) | Переводы и локализации | Прочее |
My View | View Issues | Change Log | Roadmap | Search |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0002085 | SAS.Планета | [All Projects] Хотелка | public | 12-08-2013 18:04 | 14-04-2020 06:39 | ||||
Reporter | zed | ||||||||
Assigned To | vdemidov | ||||||||
Priority | normal | Severity | minor | Reproducibility | have not tried | ||||
Status | closed | Resolution | won't fix | ||||||
Platform | OS | OS Version | |||||||
Product Version | 121010 | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0002085: PascalScript: разрешить изменять версию карты из скрипта | ||||||||
Description | Это нужно, чтобы можно было делать автообновляемые карты для некоторых сервисов. | ||||||||
Additional Information | Насколько я понимаю, для реализации хотелки, в билдер скриптов (TTileDownloadRequestBuilderPascalScript) нам нужно пробросить конфиг IMapVersionConfig и сравнивать значение переменной "Version", вернувшейся из скрипта, на равенство той, что хранится в конфиге. Ну и, соответственно, обновлять конфиг при различии этих значении. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Relationships | |||||||||||
|
Notes | |
(0012343) vasketsov (manager) 12-08-2013 18:29 |
А точно надо в обычный скрипт генерации урла пихать такую возможность? Может имеет смысл сделать отдельный скрипт или запрос (и в крайнем случае запускать его по кнопке типа "проверить обновления" в свойствах карты)? Тогда же кстати можно будет допилить поиск доступных снимков, потому что например при поиске снимков по бингу возвращается как раз актуальная версия. Её вполне можно было бы куда-нибудь сохранять, а потом читать и сравнивать. А потенциально надо наверное вообще уметь сообщать качалкой в сас, что скачанный тайл вот именно такой-то версии, а не Version. |
(0012344) zed (manager) 12-08-2013 18:38 |
>А точно надо в обычный скрипт генерации урла пихать такую возможность? Пока нету других скриптов, это единственное место, где можно сделать такую проверку, и я готов это реализовать, благо что там всё достаточно примитивно. С отдельным же скриптом всё несколько сложнее и код нужно ковырять гораздо глобальнее, на что я не готов решиться. |
(0012347) vasketsov (manager) 12-08-2013 19:36 |
>там всё достаточно примитивно Ой не уверен, явно мы с тобой друг друга не понимаем ))) вот сам посуди. Урл для проверки новой версии меняется раз в год или сильно реже. Чемпион тут яндекс, его API за время моих наблюдений менялось трижды (с точки зрения разбора регуляркой на перле, и то один раз только потому что я поленился сделать опциональными кавычки). В этом смысле этот урл для проверки можно просто указать в zmp, плюс несколько общих параметров (например шаблон regexp и номер версии на выходе, если шаблон сложный), всё в отдельной секции. Надо - пальцем проверил обновления по кнопке. Надо - автоматически при старте. Даже вообще без скрипта можно. А можно и со скриптом. Но отдельно и независимо. Хотя бы даже в отдельном низкоприоритетном фоновом потоке по всем доступным или включённым картам. Теперь давай представим, что запрос для проверки версии и его разбор реально закомпилились в паскальскрипт. Самый первый вопрос - нафига? Обновления в лучшем случае пару раз в месяц. Какой-нибудь важный параметр сменился (не сейчас, так в будущем) - скрипт перекомпиляется. Опять же имеет тот самый первый вопрос - нафига? Этj же всё лишнее время работы. Ну допустим забили мы на время работы, компилится скрипт один раз, всё работает. Но как юзеру выбрать, надо ли ему вообще это обновление версии? А как сделать такую проверку обновления только при скачке первого тайла? А если качаем сутки, и за это время карта обновилась (бинг как-то трижды обновил версию за сутки, причём с откатом назад, а через день это повторилось)? Эти вопросы технически легко реализуемы, но любая реализация по-любому приводит к тому, что в zmp (или в память "карты" для единичности проверки) надо что-то писать, плодить параметры, пропихивать их в скрипт и т.п. Я если честно совсем не вижу, где тут что может быть "достаточно примитивно". Но что ещё важнее - не вижу смысла это делать именно так. Если проверка обновления выполняется автоматически в скрипте закачки, есть как минимум два варианта: либо скрипт проверки версии пишется в zmp (в репо) для всех, и в zmp же эту проверку обновления отключаем (по умолчанию или если она не нужна), либо скрипт проверки версии в zmp для всех не пишется, и надо его вкорячивать руками. Оба варианта лично мне кажутся издевательством над юзерами. Сравни с нормальной реализацией: проверка отдельно (скриптом или регуляркой - неважно), хотья по кнопке, хоть при старте, хоть отдельным потоком, хоть дополнительно по запуску поиска доступных снимков, хоть по изменению файла в папке zmp,... - а качалка живёт своей жизнью и не меняет Version сама по себе, а лишь нюхает его изменения. Есть ещё одно обоснование, почему лучше делать отдельно. Это вариант скачки тайлов не паскальскриптами, а другими скриптами (да сейчас пока только SACS, но сути это не меняет). Разделение логики на разные скрипты позволит вообще говоря решать разные задачи чем удобнее (а например если версия выдирается прямо из корневого html - проще и быстрее и удобнее простое регулярное выражение). |
(0012350) vdemidov (manager) 12-08-2013 20:16 |
Я тоже за то, что бы сделать отдельный скрипт для получения актуальной версии карты. Согласен со всеми аргументами vasketsov, плюс я за соблюдение принципа единственной обязанности. |
(0012353) zed (manager) 13-08-2013 06:02 |
У меня есть убойный аргумент: мой вариант может быть реализован за полчаса и оно будет работать уже в завтрашней ночнушке. Вариант vasketsov гибче и лучше, с точки зрения бОльших возможностей в использовании, но чтобы это всё реализовать нужно ждать очень долго. Допустим, в SACS это может появиться за неделю, но вот на SAS рассчитывать не приходится... тикет будет висеть до 20-го года. Я хочу дать возможность продвинутым пользователям писать для себя zmp в которых они сами могут регулировать периодичность проверки версий и проч., изменением кода скрипта, без задействования/добавления каких-либо параметров в params.txt или гуй программы. Оно в общем-то и сейчас можно писать в скрипте проверку версии и юзать новые версии, игнорируя значение переменной Version, НО проблема в том, что версионное хранилище никак не уведомляется о смене версии и тайлы сохраняются не под той версией, что мы реально выкачиваем. Вот этот единственный момент, который жизненно необходимо реализовать (в отличии от всех тех плюшек, перечисленных vasketsov, без которых мы сейчас живём и в ус не дуем), для правильной работы скрипта с версионным хранилищем. vdemidov Если не готов принять мой код с реализацией тикета, как я описал это в доп. сведениях - закрывай тикет. Если решишь, что будешь реализовывать всё что описал vasketsov, то лучше заводи новый тикет и ставь там оптимистичную дату реализации. |
(0012354) zed (manager) 13-08-2013 06:45 |
Меня если честно, очень достали нубские вопросы типа: "SAS качает старые снимки, хотя в браузере уже новые" и всё тот же ответ: "Обновите версию". А небольшой доработкой скриптов, я могу написать карту GoogleSatAuto.zmp с автоматической проверкой версии при запуске, сделать эту карту дефолтной при запуске SAS и облегчить тем самым жизнь и нубам и пользователям форума. Да, я согласен - хорошо бы в SAS появился удобный и гибкий инструмент проверки версий, но пока его нет, предложенное решиние, которое обходится малой кровью, но решает таки проблему, имхо имеет право на жизнь. |
(0012355) vdemidov (manager) 13-08-2013 07:13 |
Увы, но это не решение малой кровью, а адский костыль, который потом еще и нельзя будет выпилить сохранив совместимость с zmp. > но чтобы это всё реализовать нужно ждать очень долго. Ну да, если ждать, то - долго, а вот сам бы вполне мог и реализовать. На первое время достаточно добавить новый тип скрипта и кнопочку в ГУЙ параметров карты. Добавить проверку версии при первом обращении после старта программы тоже можно, хотя и несколько сложнее. |
(0012357) zed (manager) 13-08-2013 07:25 |
>Ну да, если ждать, то - долго, а вот сам бы вполне мог и реализовать. А потом ты назовёшь это ещё одним адским костылём и выпилишь на корню. Нет уж - разбирайся сам. >На первое время достаточно добавить новый тип скрипта и кнопочку в ГУЙ параметров карты. При таком раскладе ещё нету никакого автообновления. Вместо того, чтобы писать на форумах "Обновите версию", мы будем писать "Нажмите кнопочку обновления версии". |
(0012358) vdemidov (manager) 13-08-2013 07:31 |
> А потом ты назовёшь это ещё одним адским костылём и выпилишь на корню. Ну так давай через пул-реквест. Обсудим все вопросы и претензии если они будут. > Нет уж - разбирайся сам. А вот это уже на твоей совести. >Вместо того, чтобы писать на форумах "Обновите версию", мы будем писать "Нажмите кнопочку обновления версии". Ну это будет на порядок проще объяснить и выполнить, так что польза будет заметная. |
(0012360) vdemidov (manager) 13-08-2013 07:43 |
PS: По поводу пул-реквестов. Я готов тоже все изменения вносить тоже через пул реквесты и мержить их в основную ветку только после твоего ревью. |
(0012361) zed (manager) 13-08-2013 07:44 |
>А вот это уже на твоей совести. Каждая задача имеет свою ценность, определяемую отношением получаемой выгоды к затраченным ресурсам (человеко-часы). Так вот, вариант с адским костылём имеет максимальное значение выгода/затраты, а ценность реализации "без костылей" стремится к нулю из-за неоправданно-больших затрат на реализацию, при сравнительно низкой выгоде. Поэтому наоборот, моя совесть спокойна и загрызла бы меня, если бы я взялся за менее ценную задачу, когда стоит вагон и маленькая тележка гораздо более насущных проблем. |
(0012362) zed (manager) 13-08-2013 07:47 |
>PS: По поводу пул-реквестов. Я готов Не стоит. |
(0012363) vdemidov (manager) 13-08-2013 07:57 |
> загрызла бы меня, если бы я взялся за менее ценную задачу, когда стоит вагон и маленькая тележка гораздо более насущных проблем. Ну это твое мнение. Мое мнение такое, что в САС и так хватает костылей и технического долга, что бы добавлять новые без черезвычайной необходимости. А чистое решение без костылей данного вопроса не настолько сложнее твоего предложения что бы городить костыли, которые потом аукнуться. Это не говоря уже о том, что мне в принципе не нравится поведение, когда я задал в настройках версию, а скрипт взял и поменял ее по своему усмотрению. Только не нужно мне рассказывать про то что можно полезть в скрипт и убрать - половина пользователей просто не найдет нужный скрипт. |
(0012364) zed (manager) 13-08-2013 08:00 |
>мне в принципе не нравится поведение Ну так не используй этот zmp и всё. Это же не предлагается как безальтернативная замена, а просто дополнительная карта для того же сервиса, с единственным отличием - автоообновлением. |
(0012369) vasketsov (manager) 14-08-2013 08:07 |
>НО проблема в том, что версионное хранилище никак не уведомляется о смене версии и тайлы сохраняются не под той версией, что мы реально выкачиваем. Ну тогда я предлагаю реализовать именно это, то есть то же что было написано в конце первого моего комментария к этой теме: чтобы можно было вернуть версию тайла из скрипта, руками, произвольную. Для этого всего лишь надо завести новый параметр для версии тайла, и именно его использовать при сохранении тайла в хранилище. Дело в том, что это самостоятельая фича, которая потребуется независимо от того, будет или нет проверялка обновления версии. В некоторых тайлах внутри (в exif) есть информация о том, что можно считать уникальной версией, так что формально такой разбор тайла вполне может существовать и быть полезен. Ну и соответственно два соседних запроса могут вернуть тайлы совсем разных версий. А опция для автообновления версии может быть очень простой: по сути это будет слежение за изменением версии, и если прилетает более высокая версия, чем указана для карты, то после получения тайла и его версии от качалки можно (если эта опция включена) повысить версию карты. Для некоторых карт слежение за уменьшением версии также необходимо (bing минимум трижды уменьшал версию, и на яндексе если сравнивать как строки, бывает уменьшение, типа 3.99.0 -> 3.101.0, хотя на это есть logical sorting). Первый запуск можно в теории легко идентифицировать, если для zmp включить куки, по отсутствию этих самых кук. Попробуй, может быть такая более простая реализация получится. Тем более что даже если будет полная реализация фичи (авто)обновления версии, это всё равно будет полезно. |
(0012370) zed (manager) 14-08-2013 08:54 |
Именно это и было моей первой мыслью: создавать новый интерфейс IMapVersionInfo для тайла, если из скрипта пришла новая версия. Но возник вопрос, что в гуе у нас версия останется прежней и пользователь вообще никак не узнает, что качаются тайлы другой версии. Сейчас-то никаких фич мониторинга за версиями нету. Вот и было решено изменять версию в гуи из скрипта, чтобы всё было прозрачно. >Для этого всего лишь надо завести новый параметр для версии тайла Зачем какой-то ещё параметр? Сейчас переменная Version используется как ReadOnly и записываемые в неё значения (из скрипта) игнорируюся. Достаточно сделать её ReadWrite и всё. |
(0012371) vasketsov (manager) 14-08-2013 09:32 |
>Но возник вопрос, что в гуе у нас версия останется прежней У нас вообще есть некая беда с версиями, в том плане, что почему-то версия отображения карты соответствует версии закачки. Даже несмотря на недавние пописки на тему фиксации версии при операциях с выделенной областью, всё равно исходным значением для версии закачки является версия отображения карты, хотя вообще говоря это не всегда адекватно ситуации. И если делать автообновление версии скачки и извещение об этом - переключать версию отображения на НОВОЕ значение немного туповато, ибо смотреть ещё совсем нечего ))))). Отпишу-ка кстати это в новую тему. >Достаточно сделать её ReadWrite Ну тебе виднее, наверняка ты там уже ковырялся, а я сто лет не смотрел. Если дальше одной скачки не пролетит это изменение (ну то есть, с этой версией упадёт в хранилище, и всё) - ваще круто и просто будет. |
(0012374) zed (manager) 14-08-2013 09:54 |
Круто-то оно круто, но поскольку в гуе версия не изменится, пользователь так и будет смотреть на старую карту, хотя в кэше уже будут новые тайлы. Т.е. проблема "SAS показывает старые снимки" останется. |
(0012388) vasketsov (manager) 14-08-2013 10:39 |
>проблема "SAS показывает старые снимки" останется Информирование юзера об актуальности снимков - вообще отдельная проблема. Вот давай попробуем абстрагироваться от ситуации тупого юзера. Допустим, что версии сравнИмы (гугл, бинг, ну яндекс, но не dg и не роскосмос). Может ли быть вообще интересно уведомление о том, что в хранилище есть более новые версии, чем версия для отображения? Вот на поверхности варианты работы. Вариант 1 - версия руками не правится (возможно, обновляется вверх через zmp или автообновлением). Если появится ползунок как в GE с версиями в рамках экрана, решит это задачу уведомления, что где-то на экране показывается протухший тайл? А если обновится тайл с предпредпоследней версии на предпоследнюю (правая граница ползунка не изменится)? Вариант 2 - версия руками не правится. Есть более новая версия, но в рамках экрана нет тайлов с ней, то есть все тайлы актуальны. Отсутствие такого уведомления может быть использовано как признак актуальности картинки? Вариант 3 - версия руками понижается (для целей просмотра). И после работы забыли её вернуть. Надо сообщать об этом? Когда? зы. Этот вариант сильно порешится, если обновление не будет трогать версию для отображения, но тем не менее. >пользователь так и будет смотреть на старую карту Вообще говоря, не обязательно. Если в zmp не указана версия, и включено показывать последнюю, не знаю как в версионном беркли, а вообще говоря можно показывать тайл с последней версией. Надо только в первый раз получить 134, и потом пропихивать его между запусками скрипта. Получится неверсионный zmp для гугла над версионным хранилищем, да ещё и с автообновлением. |
Users who viewed this issue | |
User List | Anonymous (2558x), aflexus (3x), vasketsov (1x) |
Total Views | 2562 |
Last View | 21-11-2024 13:20 |
Issue History | |||
Date Modified | Username | Field | Change |
12-08-2013 18:04 | zed | New Issue | |
12-08-2013 18:29 | vasketsov | Note Added: 0012343 | |
12-08-2013 18:38 | zed | Note Added: 0012344 | |
12-08-2013 19:36 | vasketsov | Note Added: 0012347 | |
12-08-2013 20:16 | vdemidov | Note Added: 0012350 | |
13-08-2013 06:02 | zed | Note Added: 0012353 | |
13-08-2013 06:45 | zed | Note Added: 0012354 | |
13-08-2013 07:13 | vdemidov | Note Added: 0012355 | |
13-08-2013 07:13 | vdemidov | Status | new => resolved |
13-08-2013 07:13 | vdemidov | Resolution | open => won't fix |
13-08-2013 07:13 | vdemidov | Assigned To | => vdemidov |
13-08-2013 07:13 | vdemidov | Status | resolved => closed |
13-08-2013 07:16 | vdemidov | Issue cloned: 0002087 | |
13-08-2013 07:16 | vdemidov | Relationship added | related to 0002087 |
13-08-2013 07:25 | zed | Note Added: 0012357 | |
13-08-2013 07:31 | vdemidov | Note Added: 0012358 | |
13-08-2013 07:43 | vdemidov | Note Added: 0012360 | |
13-08-2013 07:44 | zed | Note Added: 0012361 | |
13-08-2013 07:47 | zed | Note Added: 0012362 | |
13-08-2013 07:57 | vdemidov | Note Added: 0012363 | |
13-08-2013 08:00 | zed | Note Added: 0012364 | |
14-08-2013 08:07 | vasketsov | Note Added: 0012369 | |
14-08-2013 08:54 | zed | Note Added: 0012370 | |
14-08-2013 09:32 | vasketsov | Note Added: 0012371 | |
14-08-2013 09:54 | zed | Note Added: 0012374 | |
14-08-2013 10:39 | vasketsov | Note Added: 0012388 | |
14-04-2020 06:39 | zed | Relationship added | related to 0003652 |
My View | View Issues | Change Log | Roadmap | Search |
Copyright © 2007 - 2024 SAS.Planet Team |