Opened 11 months ago

Closed 9 months ago

Last modified 8 months ago

#665 closed улучшение (fixed)

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

Reported by: san Owned by: alx
Priority: средний Milestone: 1 очередь
Component: sw Keywords:
Cc:

Description

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

Change History (15)

in reply to:  description comment:1 by alx, 11 months ago

Replying to san:

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

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

comment:2 by san, 11 months ago

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

in reply to:  2 comment:3 by alx, 10 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...

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

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

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

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

comment:4 by san, 10 months ago

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

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

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

in reply to:  4 comment:5 by alx, 10 months ago

Replying to san:

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

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

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

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

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

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

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

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

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

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

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

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

Last edited 10 months ago by alx (previous) (diff)

comment:6 by san, 10 months ago

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

comment:7 by alx, 9 months ago

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

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

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

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

comment:8 by alx, 9 months ago

Resolution: fixed
Status: newclosed

In 2359/sw:

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

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

comment:9 by alx, 9 months ago

In 2360/sw:

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

comment:10 by alx, 9 months ago

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

comment:11 by san, 8 months ago

Алексей, глянь пожалуйста на трясущуюся дискету в демоблоке, она продолжает трястись, даже если сохранишь конфиг, кажется так быть не должно.
r2366

in reply to:  11 comment:12 by alx, 8 months ago

Replying to san:

кажется так быть не должно.

???

Replying to san:

Не вижу тут другого выхода, как принять вероятность ложноположительных срабатываний проверки.

comment:13 by alx, 8 months ago

Но я, конечно, посмотрю и подумаю, что в данном конкретном случае можно сделать...

Для справки: в данном конкретном случае ложноположительный результат был вызван элементом

    <community/>

и

    <community></community>

comment:14 by alx, 8 months ago

In 2370/sw:

Упростил вызовы создания элементов XML. See #665.

in reply to:  13 comment:15 by alx, 8 months ago

Replying to alx:

Но я, конечно, посмотрю и подумаю, что в данном конкретном случае можно сделать...

В данном конкретном случае ложноположительное срабатывание устранено.

Note: See TracTickets for help on using tickets.