= Сообщение: 1277 из 7128 ====================================== FTSC_PUBLIC = От : Michiel van der Vlist 2:280/5555 08 Oct 14 13:38:51 Кому : mark lewis 08 Oct 14 13:38:51 Тема : FTSC-5001 question FGHI : area://FTSC_PUBLIC?msgid=2:280/5555+54352697 На : area://FTSC_PUBLIC?msgid=1:3634/12.71+432eeb81 = Кодировка сообщения определена как: CP850 ================================== ============================================================================== Hello mark,
On Monday October 06 2014 15:34, you wrote to me:
MvdV>> The meaning of the flag is indpendent of its position.
ml> the meaning isn't the only thing, though... the positioning is ml> important... the first one listed is used as the prime connection ml> point...
As documented where?
ml> binkd exhibits this very well...
Binkd does not use the nodelist. It uses its own configuration files. Apples an oranges.
ml>> it would be like listing three MXes and having everyone send to ml>> the last backup instead of to the main one...
MvdV>> Wrong analogy. MXs carry a priority. There is no equivalent for MvdV>> that with IP connect information in the nodelist. There is
ml> yes there is... the position of the item within the entity's line...
As documented where?
MvdV>> possibility to list multiple addresses by repeating a flag with MvdV>> a different host name or IP address, but that's it. There is no MvdV>> implied priority by order. Wether the application uses the MvdV>> first, the last, tries them all or alternates in round robin MvdV>> fashion between sessions, is up to the implementation.
ml> right but it is still positional as those that do support this start ml> with the first one and then cycle through the others if needed...
Some may do it, others may do it in a different way.
Listing multiple flags with different hostnames/ip-addresses BTW is not the preferred way. The preferred way of listing a multi-homed system is to use one host name and attach exta A or AAAA records to it.
MvdV>> Sorry, but that is not how the system evolved. Flag meaning is MvdV>> independant of flag order. It is not what I would have choosen, MvdV>> had the decision be mine, but it was not. When introducing the MvdV>> INA flag, always listing it before the associated protocol MvdV>> flags would have been a good start. But the nodelist clerks in MvdV>> their infinite wisdom decided otherwise and now there is no way MvdV>> back. We just have to live with that.
ml> this happened because the nodelist clerks don't know these things...
It happened.
ml> many just list shite in any old order and don't understand why some ml> things are listed in the first place...
True enough. It is beyond the powers of the FTSC however to control this. We are at the mercy of the nodelist clerks.
ml>> them to operate instead of being forced to operate in the way ml>> that others tell them to operate... many drop out because of ml>> things like this that can't be resolved to suit their needs...
MvdV>> Then perhaps those people had there expectations set too high.
ml> no, they want to connect and share like others but their circumstances ml> don't allow what could be allowed if the nodelist were handled ml> differently...
There will always be people whose (perceived) needs exceeds what the system can offer and who refuse to adapt to the system but instead demand that the system adapts to them. You can't please them all, trying to do that will result in a bloathed system that pleases no one.
MvdV>> Cooperation is the key word to the smooth operation of the MvdV>> network and cooperation is not a one way street. It also means MvdV>> that one can not always get what one wants. If one can not MvdV>> accept that one can ask too much, that what one wants, is too MvdV>> outlandish, puts an unreasonable demand on the network, or MvdV>> even worse conflicts with the justifiable needs of others, then MvdV>> they will just have to choose between adapting or leaving...
ml> i see no unreasonable demand being put on the network by allowing for ml> the flags to be used for each connection point that one may use to ml> connect with a system...
I do. The systyem as it has evolved does not provide for that. It can not provide for that witout redefinig flag use. To demand that is unreasonable as it is not backward compatible. It will make existing practise fail.
MvdV>> The opportunity to introduce positional usage went out of the MvdV>> window when the nodelist clerks allowed listing the INA flag in MvdV>> an arbitrary position instead of only before the associated MvdV>> protocol flags. You should have spoken then. Now it is too MvdV>> late.
