Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции FTSC_PUBLIC
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции FTSC_PUBLIC с датами от 13 Sep 13 18:57:24 до 01 Apr 24 01:17:44, всего сообщений: 7124
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 4038 из 7124 ====================================== FTSC_PUBLIC =
От   : Michiel van der Vlist            2:280/5555         06 Dec 18 21:10:45
Кому : Markus Reschke                                      06 Dec 18 21:10:45
Тема : Candidates vision request
FGHI : area://FTSC_PUBLIC?msgid=2:280/5555+5c0984e1
На   : area://FTSC_PUBLIC?msgid=2:240/1661+5bfd8f71
= Кодировка сообщения определена как: CP850 ==================================
Ответ: area://FTSC_PUBLIC?msgid=2:240/1661+5bfd8f75
==============================================================================
Hello Markus,

On Thursday December 06 2018 18:05, you wrote to Fred Riccio:

MR> This is what I've meant with the confusion about which "standard"
MR> applies. Apparently Jerry's converter follows the undocumented feature
MR> Carol mentioned. So it would extract additional addresses which aren't
MR> intended for binkp for a node entry following the FTSC docs (if listed
MR> take just the address in the IBN flag). How do we resolve this
MR> dilemma?

We should not even try. Adding exceptions every time some idiot creates a deviation from the established standard is undoable. Yes, in theory one could create a flag to signal which interpretation of the INA flag is tio be used, Schwartz or FTS-5001.  But than we'd have to agree on the flag. And then what if someone uses the same flag with exactly the oppostie meaning. Well, we could create another flag to signal which interpreation of the flag that signals which interpreation of the INA flag is to be used. Etc, etc...

MR> If all entries for Z1 nodes follow the undocumented feature
MR> then I could add a special case to my tool to take also the addresses
MR> listed in the INA flag. And Jerry would have to do the same, just the
MR> other way around.

This is an unworkable situation. Once a standard is established, all shoukld follow it and one should not create new interpretations that conflict with the existing standard.

MR> The frustating thing is that it's hard for sortware developers to know
MR> about undocumented features.

It is not just hard, it is impossible to keep up with all the exceptions and upgrade the software if there is no limit imposed on it.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.041674 секунды