SACS: Another Clone of SAS

[vasketsov]

SACS: Another Clone of SAS

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

В настоящий момент отличия от "ночной" версии следующие (номера соответствуют багтрекеру):

- 1481 (Переделка хранилища меток)

скрытый текст: показать

Метки в SQLite, импорт и экспорт между SML и SQLite (позволяющий в том числе перейти обратно на SML при необходимости).

Поскольку SML не предлагает никаких преимуществ перед SQLite, а имеет лишь одни недостатки (кроме очевидных - тот же Midas и довесок к размеру EXE),
то потенциально он в будущем может быть будет вырезан (возможно даже вместе с параметром DBFileName, см. ниже).

Для работы SQLite требуется относительно новая версия, так как режим WAL на старых версиях SQLite не поддерживается.
Актуальная версия SQLite (только DLL) упакована в архив.

Чтобы не загадить папку с программой, миграцию (обновление БД меток) можно выполнить следующим образом:

а) в ini-шке переименовать путь до меток на значение по умолчанию:
[PATHtoMARKS]
PrimaryPath=.\MarksSQLite

б) создать указанную папку (в примере - подпапку MarksSQLite)

в) перенести туда файлы Categorymarks.sml и marks.sml (настройка пути к меткам одна, и если этот шаг не сделать, то старые метки просто не найдутся)

(зы. указание пути к меткам было доступно и ранее, старые БД с метками работают даже в папке MarksSQLite)

г) в папку MarksSQLite сложить файл Marks.SLT.0.1.sql

д) в папку с программой сложить sqlite3.dll

е) в ini-шке указать имя файла новой БД меток в виде:
[MarkNewCategory]
DBFileName=>MarksDB.sqlitedb

(зы. такая запись приведёт к тому, что при следуюещм запуске саса будет выполнено копирование существующих категорий и меток в новую БД в новом формате, если её нет - она будет создана; если копировать старые метки не надо - пишем просто DBFileName=MarksDB.sqlitedb без символа потокового копирования)

ж) -Поехали!
Запускаем программу, ждём десяток-другой секунд (минуту?) в зависимости от количества меток.
После того как программа окончательно запустится - идём в менеджер меток и смотрим что получилось.
В зависимости от результата или повторяем миграцию (закрыв программу и удалив файлы новой БД руками), или архивируем старые SML-ки для потомков в отдельную папочку на всякий пожарный.
После переноса меток при старте программы символ ">" удаляется из значения параметра DBFileName автоматически при закрытии программы.

- 1337 (Ограничение положения ползунка зумов)

скрытый текст: показать

С некоторыми недоделками типа "недоокученных" экспортов (ещё в процессе).
Включается указанием в zmp параметра ZoomList в виде строки "ZoomList=6-12,14,16,18".

- 401 (При открытии объекта Викимапии или фотографии Panoramio они открываются в мини-окне IE)

скрытый текст: показать

Сделан внутренний httpd и реализована возможность использования Mozilla ActiveX вместо IE.
Первое открытие Mozilla ActiveX немного подтормаживает, но потом всё шустро.

Требует наличия VsaEmbeddedHttpd.dll для внутреннего httpd.
DLL эта собрана из этого репозитория, она же настраивает Mozilla ActiveX для работы с прокси в соответствии с настройками SAS:
https://bitbucket.org/vasketsov/vsaembeddedproxy
Класть рядом.

Mozilla ActiveX берётся отсюда:
http://www.adamlock.com/mozilla/control.htm#download
Прямой линк:
http://www.adamlock.com/mozilla/MozillaControl1712.exe
Ставить можно куда угодно.
Его настройки в его подпапке greprefs в файле all.js
Обращаю внимание на то, что опция "брать настройки подключения из реестра" для Mozilla ActiveX очевидным образом означает "брать системные настройки Mozilla ActiveX", про реестр и IE она ничего не знает.
Ещё обращаю внимание, что для работы Mozilla ActiveX обязательно включение внутреннего httpd, для IE - не обязательно.

Параметры в ini (приведены значения по умолчанию, указывать можно только отличающиеся от приведённых):
[Internet]
UseMozilla=0
UseInternalHttpd=0
InternalHttpdEndpoint=127.0.0.1:7999

- 152 (Сохранение фотографий в кэш с panoramio)

скрытый текст: показать

Отличие от ранее убитой реализации заключается в том, что при операциях по выделенной области это будет не отдельный пункт, а галочка.
Изменений в кэше фотографий нет, старый кэш "подхватывается".
Если у кого-то остался старый настроенный вариант скрипта ParseAttachmentScript - надо заменить MakeFullURL либо на MakeEmbeddedURL (для скачанной картинки), либо на MakeOriginalURL (для ссылки на сайт).
Скачивание картинок в скрипте ParseAttachmentScript можно:
а) оставить (чтобы скачивались обе картинки сразу);
б) удалить (тогда картинки будут скачиваться автоматически только при показе через MakeEmbeddedURL).
Примеры params.txt и ParseAttachmentScript.txt для Panoramio приложены в архив.

- некоторые мелкие правки без пунктов (типа Click-ов в окне операций с выделенной областью на чекбоксах, которые не являются чекбоксами).


Покуда GPL v.3 накладывает определённые ограничения - будем их соблюдать.
Репозиторий тут: https://bitbucket.org/vasketsov/vsasas
Перенос патчиков между репозиториями возможен и судя по всему будет осуществляться по мере необходимости, желания и возможности.

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

Здесь правила предельно простые. Так как нет смысла писать про GPL, упомяну лишь об отличиях:

скрытый текст: показать

а) проект должен собираться и работать, покуда не протестировано - заливаем, но не подключаем;
б) не уверен - не берись, взялся - делай:
б1) ничего не должно отваливаться, если что-то сломано - должно быть исправлено самостоятельно или с помощью других за уместное время;
б2) отговорки типа "мне этот кусок не нужен, забью-ка я на него" хорошо подойдут только для оригинального репозитория;
б3) способ реализации должен быть устойчив к модификациям внешней среды: минимальные прогнозируемые изменения в постановке задачи не должны приводить к необходимости глобальной переделки.
в) по "стилю" (отступы и прочая) - общее правило "делай как я": ищем аналогии, не нашли - спрашиваем, что не устраивает - переделываем без поломки;
г) без Г.

В архиве кроме EXE собраны все DLL (кроме Mozilla ActiveX), нужные для описанных доработок, а также прочие файлы.

Также сложены файлы для тайлохранилища в СУБД (работа через ODBC):

скрытый текст: показать

а) файл TileStorage_DBMS.dll;
б) примеры настроек подключений TileStorage_DBMS.ini;
в) папка DBMS со скриптами;
г) подпапка DBMS\DOCS с дополнительными описаниями.

Архив тут:
http://yadi.sk/d/MNhkncjR26uuH

зы. Все кто поддерживал - всем спасибо.

[Parasite]

Проставил линки на тикеты, длиннокотов загнал под спойлеры.

[vdemidov]

Может стоит создать отдельный проект в трекере? Что бы не путались баги, хотелки и планируемые рефакторинги?

[vasketsov]

Предлагаешь дублировать тикеты? )))

[Fetser]

Подскажите пожалуйста по поводу запрета на изменение меток в SQLite. Мне желательно разграничить права у разных пользователей. Метки общие, а редактировать их могут только некоторые пользователи.
Раньше я поступал меняя атрибут файла sml на "только чтение" То есть постоянно стоит "только чтение" А при необходимости редактирования пользователь копировал их в другое место менял атрибут, редактировал, опять ставил "только чтение" и копировал их обратно для общего просмотра.
С SQLite такой фокус не проходит - программа не хочет показывать метки если стоит "только чтение"

[vdemidov]

Предлагаешь дублировать тикеты? )))

Все подряд дублировать смысла нет, а вот то, что закрываешь как фиксед, а я реализовывать не хочу, можно просто перенести. Ну а некоторые, действительно дублировать.
А некоторые, типа рид онли для SQLite меток только для твоего форка будут актуальны.

[vasketsov]

Метки общие, а редактировать их могут только некоторые пользователи

Чего можно сделать относительно просто (в порядке увеличения сложности):
1. Признак для конкретного пользователя, что он никогда ничего не правит, а только читает (для этого задумано поле g_user.u_status). Включение режима "только чтение" для пользователя надо будет выполнять не в сасе, а например в SQLite Maestro (или другой программе, где можно открыть базу меток и выполнить прямой запрос типа 'update g_user...'). Признак будет читаться при открытии БД меток, так что на лету пользователь ничего не сможет поправить, если вдруг надо будет что-то исправить - придётся менять признак, перезапускаться, править, менять признак и перезапускаться.
1а. Как вариант послабления - дополнительный признак самого пользователя, мол, я работаю в режиме только чтения. Разумеется не перекрывает административный признак "только чтение". А может и не дополнительный, а единственный, коли пользователи сами правят атрибуты и копируют SML-ки (то есть хоть и через тернии, но к звёздам правят метки).
1б. Здесь же отмечу, что в принципе аналогично (признаком в БД) можно указать для пользователя запрет экспорта меток. Импорт в режиме "только чтение" и так обломается. Но это немного отдельная тема.
2. У каждой категории и метки есть ссылка на её владельца (поле id_owner). По умолчанию при создании категории или меки туда попадает идентификатор пользователя, который её создал (в этом смысле при миграции там у всех одно и то же значение, но это только вопрос первоначальной настройки). Для разграничения прав на операции с объектом в зависимости от текущего пользователя и владельца объекта задуманы поля статусов в таблицах категорий и меток. Владелец всегда имеет весь набор полномочий. Дополнительно могут быть реализованы например такие варианты:
а) владелец метки может запретить всем другим её изменять (причём это будет касаться только этой конкретной метки);
б) владелец метки может запретить всем другим её удалять;
в) владелец категории может запретить создавать в ней метки всем другим пользователям;
г) владелец категории может запретить её удалять всем другим пользователям;
д) и прочее аналогичное по сути.
Ограничения в реализации ограничений в основном связаны с уникальностью категорий и осутствием групп пользователей (хотя в приниципе их можно даже и обойти):
а) не планировалось (хотя в принципе возможно) ограничить видимость категории, так как другой может захотеть создать категорию с тем же именем (соответственно если так сделать - будет ошибка неуникальности при видимом отсутствии категории с таким именем);
б) нельзя разрешить или запретить какую-либо операцию определённому набору пользователей, есть только владелец, и есть все остальные.


Чем проще выберете устраивающий вариант - тем быстрее выдам, и тем быстрее оно будет работать.

С SQLite такой фокус не проходит

Разумеется так не надо делать.

[vasketsov]

то, что закрываешь как фиксед, а я реализовывать не хочу, можно просто перенести

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

некоторые, типа рид онли для SQLite меток только для твоего форка будут актуальны

Это кстати пример некорректной формулировки. Дело в том, что функциональность ограничений на метки - исключительно техническая проблема, и не проблема хранилища.
И после реализации доработки "рид онли метки" например при реализации нового типа хранилища меток (в СУБД или ещё как) режим "рид онли метки" также должен работать.
В этом смысле правильная формулировка - просто "рид онли метки" без уточнения.
Просто у тебя она уйдёт на 2020 год для самых неунывающих оптимистов.

[Fetser]

Чем проще выберете устраивающий вариант - тем быстрее выдам, и тем быстрее оно будет работать.

Если можно ввести параметр на "Только чтение" базы меток в SASPlanet.ini был бы самый удобный вариант. Поскольку программа у всех общая, а вот файл конфигурации индивидуальный.

[vdemidov]

то, что закрываешь как фиксед, а я реализовывать не хочу, можно просто перенести

Ну если так принципиально - можно и сделать (хотя если потом вдруг захочешь реализовать?).

Если захочу, сделаю клон хотелки.

Важно такую важную часть как обсуждение хотелок не поделить, покуда исходные задачи можно формулировать без подробностей.

Где раньше реализовано, туда и идет основная хотелка с обсуждением, а тому кто позже поможет ссылка на relative

некоторые, типа рид онли для SQLite меток только для твоего форка будут актуальны

Это кстати пример некорректной формулировки. Дело в том, что функциональность ограничений на метки - исключительно техническая проблема, и не проблема хранилища.

Тоесть ты хочешь сказать, что твоя версия запустится с ReadOnly носителя типа компакта или шары с ReadOnly доступом? Я так понял оно просто не запустится или метко не покажет, а sml база будет работать на ура.

Просто у тебя она уйдёт на 2020 год для самых неунывающих оптимистов.

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