#665 closed улучшение (fixed)
Подсказка о несохраненной в ПЗУ конфигурации
| Reported by: | san | Owned by: | alx |
|---|---|---|---|
| Priority: | средний | Milestone: | 1 очередь |
| Component: | sw | Keywords: | |
| Cc: |
Description
Из моей практики техподдержки замечено, что пользователи часто забывают сохранить конфигурацию в ПЗУ или после загрузки файла конфига забывают перезапустить swd, а потом после перезагрузки блока искренне удивляются что он запускается с другим конфигом.
Предлагаю в веб-интерфейсе подсказывать пользователю когда текущая конфигурация блока отличается от той что сохранена в ПЗУ.
Визуально подсказка может быть в виде изменения значка "дискета", на например, "горящая дискета".
Change History (15)
comment:1 by , 9 months ago
follow-up: 3 comment:2 by , 9 months ago
На мой взгляд это должен быть какой-то простой способ, индицирующий, что конфигурация может отличаться от той что в ПЗУ. Например, по таймстампу. Загружать в ОЗУ таймстамп из конфигурации в ПЗУ и если пользователь хоть что-нибудь изменил, менять таймстамп в ОЗУ. Или использовать таймстамп + имя блока.
comment:3 by , 9 months ago
Replying to san:
На мой взгляд это должен быть какой-то простой способ, индицирующий, что конфигурация может отличаться от той что в ПЗУ.
Я, конечно, приветствую, чтобы способ был простой. Но это не тот ответ, которого я ждал. :) Я имел в виду, какой конкретно критерий, характеристика, признак и т.п. предлагается для определения различия в конфигурации. Например вот такая конфигурация:
<?xml version="1.0" encoding="UTF-8"?> <config> <tag/> </config>
и вот такая конфигурация:
<?xml version="1.0" encoding="UTF-8"?> <config> <tag/> </config>
различаются количеством пробелов перед <tag/>! Но семантически они одинаковы.
Или вот еще пример:
<?xml version="1.0" encoding="UTF-8"?> <config> <board slot="5"/> <board slot="9"/> </config>
<?xml version="1.0" encoding="UTF-8"?> <config> <board slot="9"/> <board slot="5"/> </config>
Здесь поменяли местами конфигурации плат в слотах 5 и 9. Опять же семантически это одна и та же конфигурация (так как порядок следования конфигураций плат не важен), но два разных документа XML...
Например, по таймстампу.
Загружать в ОЗУ таймстамп из конфигурации в ПЗУ и если пользователь хоть что-нибудь изменил, менять таймстамп в ОЗУ. Или использовать таймстамп + имя блока.
Этот пример мне совсем непонятен... То есть например изменили что-то в конфигурации - сразу изменили и таймстамп, и таймстампы документов в файле и в ОЗУ стали разными. Это понятно. Но есть пара "но".
Во-первых, например, изменил пользователь какую-то настройку, а потом вернул ее назад - а таймстампы все равно остались разные, хотя конфиги в файле и в ОЗУ одинаковые...
Во-вторых, если при любом изменении конфига менять таймстамп, то я не понимаю, чем это отличается от просто флага, устанавливаемого при любом изменении конфигурации. Зачем вообще в данном примере нужен таймстамп?
follow-up: 5 comment:4 by , 9 months ago
чем это отличается от просто флага
Ну смысл моего предложения - флаг, единственное что таймстамп позволяет поймать момент когда пользователь загрузит в ПЗУ файл любым способом (таймстамп будет отличаться, хоть и не со 100% вероятностью). Логичнее вместо таймстампа использовать хэш файла конфига, тогда можно будет точно узнать когда файл будет заменён.
Я понимаю что семантически сравнить конфигурации довольно сложно, поэтому мне хотелось обойтись каким-то простым критерием типа флага.
comment:5 by , 9 months ago
Replying to san:
чем это отличается от просто флага
Ну смысл моего предложения - флаг,
Хорошо. Идея флага, говорящего о том, что конфигурация изменилась, мне понятна. Однако реализацию этой идеи я никак не могу назвать простой (в comment:2 ты писал, что это должен быть простой способ). У нас в блоке сейчас поддерживается около полусотни типов плат. Почти в каждой плате есть несколько конфигурационных параметров. Для реализации данной идеи потребуется в каждом месте кода, где записывается значение каждого конфигурационного параметра каждого типа платы добавить установку флага. Даже с учетом того, что один и тот же код может обслуживать несколько похожих типов плат (например SM-01, SM-02, SM-03), это сотни мест в исходном коде...
Хотелось бы что-нибудь попроще... :)
единственное что таймстамп позволяет поймать момент когда пользователь загрузит в ПЗУ файл любым способом
??? Каким образом? Таймстамп - это время сохранения конфигурации в файл - иными словами, это время, когда пользователь нажал "Сохранить конфигурацию" в веб-интерфейсе...
(таймстамп будет отличаться, хоть и не со 100% вероятностью).
??? Отличаться от чего? Что-то я потерял мысль... :(
Логичнее вместо таймстампа использовать хэш файла конфига, тогда можно будет точно узнать когда файл будет заменён.
Согласен. Именно так плата SW-01, находящаяся в резерве, определяет, изменился ли конфиг-файл, получаемый от активной платы.
Я понимаю что семантически сравнить конфигурации довольно сложно, поэтому мне хотелось обойтись каким-то простым критерием типа флага.
Мне тоже хотелось бы попроще. Но см. комментарий выше - если полагаться на точное совпадение документов, будет вероятность ложноположительного срабатываний такой проверки. Например пользователь скачал файл, открыл его в редакторе, пересохранил "ничего не меняя", а потом записал обратно в плату. А хэш изменился, потому что, например, редактор заменил все переводы строк на комбинации CRLF... :)
comment:6 by , 9 months ago
Не вижу тут другого выхода, как принять вероятность ложноположительных срабатываний проверки. Думаю что в большинстве случаев (во всех "обычных сценариях работы") проверка хэша файла будет достаточным критерием.
comment:7 by , 8 months ago
В выбранном методе есть одна проблема. Когда действующий конфиг преобразуется в документ XML, это осуществляется не путем модификации уже имеющегося в документе элемента (например <board/>), а путем его полного пересоздания, то есть существующий элемент удаляется, и создается совершенно новый, который добавляется в конец документа. Следствием этого является возможность изменения порядка следования элементов в документе даже без изменения конфигурации. Например вытащили из блока плату - и порядок следования элементов <board/> в документе изменился (конфиг удаленной платы переместился вверх).
Это сделано для упрощения (чтобы не надо было для каждого параметра искать вложенный элемент или атрибут элемента). Возможно, что зря. :)
Для устранения влияния порядка следования элементов на результат я реализовал сортировку элементов верхнего уровня (непосредственных потомков корня <config/>). Элементы сортируются по имени, а если это элемент <board/>, которых может быть много, они дополнительно сортируются сначала по номеру слота, а затем по имени платы. Полученный в результате документ можно перевести в текст и вычислить хэш, по которому можно сравнивать идентичность двух документов. Попробую завтра реализовать это все и посмотреть, как будет работать...
Но описанная выше сортировка не спасет от случая, когда, например, в блок вставили новую плату (которой раньше никогда не было)...
comment:10 by , 7 months ago
Потестировать улучшение до релиза можно обновившись из репозитория http://alx.adc-line.ru/ipk
follow-up: 12 comment:11 by , 7 months ago
Алексей, глянь пожалуйста на трясущуюся дискету в демоблоке, она продолжает трястись, даже если сохранишь конфиг, кажется так быть не должно.
r2366
comment:12 by , 7 months ago
follow-up: 15 comment:13 by , 7 months ago
Но я, конечно, посмотрю и подумаю, что в данном конкретном случае можно сделать...
Для справки: в данном конкретном случае ложноположительный результат был вызван элементом
<community/>
и
<community></community>
comment:15 by , 7 months ago
Replying to alx:
Но я, конечно, посмотрю и подумаю, что в данном конкретном случае можно сделать...
В данном конкретном случае ложноположительное срабатывание устранено.
Replying to san:
Как именно предлагается определять, отличается ли конфигурация блока от той, что сохранена в ПЗУ?