на главнуюВсе эхи RU.FTRACK
войти ?

Rntrack 2.1.2

От Alexey Fayans (2:5030/1997) к Michael Dukelsky

В ответ на Заголовок предыдущего сообщения в треде (Имя Автора)


Hello Michael!

On Sun, 03 May 2020 at 17:19 +0300, you wrote to me:

AF>>>> Я не возражаю против обнуления флагов при упаковке, когда
AF>>>> упаковываются мои письма. Транзитные должны идти так, как их
AF>>>> отправили.
MD>>> Не нашёл, где в FTS-0001 написано, что транзитных писем это не
MD>>> касается.
AF>> А где касается, нашёл? :)
MD> Да, конечно. Все 16 битовых флагов там поделены на 2 группы:
MD> отмеченные знаком '+' не должны обнуляться перед паковкой письма в
MD> пакет; соответственно, остальные могут быть обнулены

Могут быть обнулены != должны быть обнулены.

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

Это проблемы отправляющего и получающего узлов, но никак не мои, и я принципиально не хочу их решать за других людей. Точно так же, как я не хочу менять Н на H потому что у кого-то где-то может стоять древний софт, который может сломаться из-за этого. Люди должны решать проблемы у себя, а не с помощью транзитных узлов. Если я буду решать чужие проблемы, люди никогда о них не узнают и не исправят у себя ничего.

AF>> Транзитные письма не надо трогать, задача
AF>> транзитного узла - переслать всё как есть. Если отправитель не
AF>> убрал какие-то флаги - это его проблема. Может быть он что-то
AF>> тестит и ему нужно, чтобы письмо было отправлено именно с этими
AF>> флагами.
MD> Экспериментировать нужно у себя на узле, не мешая работе других узлов.

Зависит от типа эксперимента.

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

Насколько я знаю, FPD/FTS это не запрещено, следовательно, это твоё личное мнение. Я с ним не согласен, обоснование выше.

AF>> Я всё ещё утверждаю, что любая работа с флагами - это editing. То
AF>> есть получается, я могу убрать флаг Lok, но не могу убрать или
AF>> поставить другой флаг?
MD> Алексей, тебе нравится придираться к формулировкам?

Мне не нравится, когда документация неточная, и нужно гадать или экспериментальным образом выяснять, как софт ведёт себя на самом деле. Лушчше уточнить, что именно подразумевается под изменением.

Вернёмся к нашим баранам: будет ли опция (или опции), отключающая новое поведение?


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)

Ответы на это письмо:

From: Username
Заголовок следующего сообщения в треде может быть длинным и его придется перенести на новую строку

From: Username
Или коротким

FGHI-url этого письма: area://RU.FTRACK?msgid=2:5030/1997@fidonet+5eafec87