Подсказка о несохраненной в ПЗУ конфигурации

[san]

Из моей практики техподдержки замечено, что пользователи часто забывают сохранить конфигурацию в ПЗУ или после загрузки файла конфига забывают перезапустить swd, а потом после перезагрузки блока искренне удивляются что он запускается с другим конфигом.
Предлагаю в веб-интерфейсе подсказывать пользователю когда текущая конфигурация блока отличается от той что сохранена в ПЗУ.
Визуально подсказка может быть в виде изменения значка "дискета", на например, "горящая дискета".

[alx]

Replying to san:

Предлагаю в веб-интерфейсе подсказывать пользователю когда текущая конфигурация блока отличается от той что сохранена в ПЗУ.

Как именно предлагается определять, отличается ли конфигурация блока от той, что сохранена в ПЗУ?

[san]

На мой взгляд это должен быть какой-то простой способ, индицирующий, что конфигурация может отличаться от той что в ПЗУ. Например, по таймстампу. Загружать в ОЗУ таймстамп из конфигурации в ПЗУ и если пользователь хоть что-нибудь изменил, менять таймстамп в ОЗУ. Или использовать таймстамп + имя блока.

[alx]

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...

Например, по таймстампу.
Загружать в ОЗУ таймстамп из конфигурации в ПЗУ и если пользователь хоть что-нибудь изменил, менять таймстамп в ОЗУ. Или использовать таймстамп + имя блока.

Этот пример мне совсем непонятен... То есть например изменили что-то в конфигурации - сразу изменили и таймстамп, и таймстампы документов в файле и в ОЗУ стали разными. Это понятно. Но есть пара "но".

Во-первых, например, изменил пользователь какую-то настройку, а потом вернул ее назад - а таймстампы все равно остались разные, хотя конфиги в файле и в ОЗУ одинаковые...

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

[san]

чем это отличается от просто флага

Ну смысл моего предложения - флаг, единственное что таймстамп позволяет поймать момент когда пользователь загрузит в ПЗУ файл любым способом (таймстамп будет отличаться, хоть и не со 100% вероятностью). Логичнее вместо таймстампа использовать хэш файла конфига, тогда можно будет точно узнать когда файл будет заменён.

Я понимаю что семантически сравнить конфигурации довольно сложно, поэтому мне хотелось обойтись каким-то простым критерием типа флага.

[alx]

Replying to san:

чем это отличается от просто флага

Ну смысл моего предложения - флаг,

Хорошо. Идея флага, говорящего о том, что конфигурация изменилась, мне понятна. Однако реализацию этой идеи я никак не могу назвать простой (в comment:2 ты писал, что это должен быть простой способ). У нас в блоке сейчас поддерживается около полусотни типов плат. Почти в каждой плате есть несколько конфигурационных параметров. Для реализации данной идеи потребуется в каждом месте кода, где записывается значение каждого конфигурационного параметра каждого типа платы добавить установку флага. Даже с учетом того, что один и тот же код может обслуживать несколько похожих типов плат (например SM-01, SM-02, SM-03), это сотни мест в исходном коде...

Хотелось бы что-нибудь попроще... :)

единственное что таймстамп позволяет поймать момент когда пользователь загрузит в ПЗУ файл любым способом

??? Каким образом? Таймстамп - это время сохранения конфигурации в файл - иными словами, это время, когда пользователь нажал "Сохранить конфигурацию" в веб-интерфейсе...

(таймстамп будет отличаться, хоть и не со 100% вероятностью).

??? Отличаться от чего? Что-то я потерял мысль... :(

Логичнее вместо таймстампа использовать хэш файла конфига, тогда можно будет точно узнать когда файл будет заменён.

Согласен. Именно так плата SW-01, находящаяся в резерве, определяет, изменился ли конфиг-файл, получаемый от активной платы.

Я понимаю что семантически сравнить конфигурации довольно сложно, поэтому мне хотелось обойтись каким-то простым критерием типа флага.

Мне тоже хотелось бы попроще. Но см. комментарий выше - если полагаться на точное совпадение документов, будет вероятность ложноположительного срабатываний такой проверки. Например пользователь скачал файл, открыл его в редакторе, пересохранил "ничего не меняя", а потом записал обратно в плату. А хэш изменился, потому что, например, редактор заменил все переводы строк на комбинации CRLF... :)

[san]

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

[alx]

В выбранном методе есть одна проблема. Когда действующий конфиг преобразуется в документ XML, это осуществляется не путем модификации уже имеющегося в документе элемента (например <board/>), а путем его полного пересоздания, то есть существующий элемент удаляется, и создается совершенно новый, который добавляется в конец документа. Следствием этого является возможность изменения порядка следования элементов в документе даже без изменения конфигурации. Например вытащили из блока плату - и порядок следования элементов <board/> в документе изменился (конфиг удаленной платы переместился вверх).

Это сделано для упрощения (чтобы не надо было для каждого параметра искать вложенный элемент или атрибут элемента). Возможно, что зря. :)

Для устранения влияния порядка следования элементов на результат я реализовал сортировку элементов верхнего уровня (непосредственных потомков корня <config/>). Элементы сортируются по имени, а если это элемент <board/>, которых может быть много, они дополнительно сортируются сначала по номеру слота, а затем по имени платы. Полученный в результате документ можно перевести в текст и вычислить хэш, по которому можно сравнивать идентичность двух документов. Попробую завтра реализовать это все и посмотреть, как будет работать...

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

[alx]

In 2359/sw:

Реализована новая функция - напоминании о несохраненных изменениях конфигурации.

Периодически swd выполняет сравнение конфигурации в текущем конфиг-файле
и действующей конфигурации. При обранужении различий в веб-интерфейсе
начинает периодиечски трястить кнопка "Сохранить конфигурацию", привлекая внимание
пользователя к неободимости ее нажать. Closes #665.

[alx]

In 2360/sw:

Добавлены два забытых в предыдущем коммите файлов. See #665.

[alx]

Потестировать улучшение до релиза можно обновившись из репозитория ​http://alx.adc-line.ru/ipk