|
Notes |
|
|
|
|
А локал версия 7-го GE будет? |
|
|
|
(0012706)
|
|
zed
|
|
31-08-2013 06:13
|
|
|
А зачем оффтопить? Всё что касается GE.local спрашивайте вот >>тут<< |
|
|
|
|
Может проще будет тайлохранилище геокэшера сразу загнать в один из напрямую поддерживаемых кэшей саса?
Тогда и либа не нужна будет совсем.
Требование к хранилищу - параллельная запись из одного приложения, чтение из других, тот же беркли же должен справиться. А вообще при соблюдении интерфейса и SQLite подойдёт и любая СУБД тоже. |
|
|
|
(0012710)
|
|
zed
|
|
31-08-2013 07:45
|
|
>Тогда и либа не нужна будет совсем.
Ну а собственно GeoCacher как сможет писать в эти хранилища? Либу писать всё-равно нужно, а вот уже потом можно будет подключить её и к SAS и к кэшеру.
Поэтому для начала, я сделаю тайловый кэш (только для чтения), подключу его к SAS, а потом буду смотреть, как это вкорячить в кэшер в режиме RW (ещё же надо учесть, что там кроме картинок да рельефа, есть кучка специфических типов данных). |
|
|
|
|
>GeoCacher как сможет писать в эти хранилища?
Точно также как сас сейчас - через интерфейс тайлохранилища.
Или там сасового API не хватит?
>есть кучка специфических типов данных
Так вроде же Tilestorage-у же пофигу, что хранить, лишь бы запросы в него шли с одинаковым ContentType-ом (можно даже бредовым)? Понаделать базок под каждый "специфический тип данных" (в смысле, под каждый разный запрос, одну под terrain, одну под историю,...) и в каждой базке версией рулить.
Сейчас, как я понял, ты хочешь обучить сас работать с хранилищем GC. А я предлагаю ровно обратную процедуру. Выгода будет неоспорима. Правда вот насколько это сложно - тебе конечно виднее.
Ты ж как-то сам уже приходил к выводу, что кэш CG не оптимален с точки зрения хранения гигабайтов данных. Вот я и предлагаю оперативное вмешательство в неоптимальное место, а не в то, что работает с неоптимальным местом. |
|
|
|
(0012712)
|
|
zed
|
|
31-08-2013 08:25
|
|
>Или там сасового API не хватит?
У САС-а нету публичного API для тайлохранилищ. Поэтому нужна либа с этим API, которую я уже смогу юзать в GC. |
|
|
|
|
>нету публичного API
Я про ITileStorage сотоварищи.
Разве нельзя их напрямую залинковать в GC, как это делается в сасе? Ну может с микродопиливаниями? |
|
|
|
(0012714)
|
|
zed
|
31-08-2013 08:47
(edited on: 31-08-2013 08:48) |
|
>Я про ITileStorage сотоварищи.
Я понимаю. А ты смотрел, сколько ещё сопутствующих интерфейсов оно за собой тянет? Там половину САС-а нужно прилинковать. Причём, САС-овские интерфейсы могут юзать и строки и всё что хочешь. И никаких safecall вызовов по большому счёту.
|
|
|
|
|
>смотрел, сколько ещё сопутствующих интерфейсов оно за собой тянет?
Разумеется.
В проекте sas_to_gme именно это и делается )))
Только там ещё и zmp и maptype и рисовалка линкуются - суммарный размер DLL 2 мега. У тебя с хранилищем будет скорее всего сильно меньше 1 мегабайта довесок. Причём сами интерфейсы сильно много же не жрут, если реализация не залинкуется.
>никаких safecall вызовов
Разумеется. |
|
|
|
(0012716)
|
|
zed
|
|
31-08-2013 09:40
|
|
>В проекте sas_to_gme именно это и делается
Ну так с MapEdit-ом ты общаешься по его API, а внутри dll ты просто имеешь урезанную копию САС. И ты предлагаешь мне точно так же встроить в GC урезанный САС, чтобы была возможность юзать его хранилища? Что-то не нравится мне эта идея. |
|
|
|
|
>внутри dll ты просто имеешь урезанную копию САС
Так точно.
А почему идея не нравится?
1. Новое хранилище - пересборка GC и всё.
2. Либа не нужна, так как сас и GC живут в одном хранилище.
3. Любые хранилища доступны, включая СУБД, где работают быстрые операции по диапазону xy.
...
Если сравнивать задачу написания нового хранилища и либы для саса, и замены интерфейса ФС для GC на интерфейс саса - я бы заведомо выбрал второе. По умолчанию даже можно обычный файлокэш держать, и работать вообще не отсвечивая хвостами саса наружу. Ну а коли есть ini и карты (буквально - если GC сложили в папку саса - значит все настройки всех хранилищ доступны как есть, даже terrain-ы) - настроить в GC, что куда падает. Ну или иначе сделать (тоже просто сасову ini-шку надо будет подсунуть), детали тут несущественны. Важно что делается это один раз, и работает с любым версионным кэшем. В том числе и будущими реализациями. За всё время существования dll, там один раз была существенная правка из-за того что рисовалку пописали, остальное - только в свойства проекта добавляю новые подпапки. Если бы столько же жил сас в GC - пришлось бы только подпапку добавить в свойства проекта с новым типом кэша и пересобрать. |
|
|
|
|
|
Там только будет одна загвоздка: я когда давным-давно начинал это, сделал под проверкой, что мы внутри DLL. Дурень был. По уму надо заменить это условной компиляцией (одна лишь робкая попытка - это vsasas rev. 715). Это я про GlobalState.pas. |
|
|
|
(0017081)
|
|
zed
|
|
16-03-2016 10:11
|
|
|