Kiun staton de NetworkManager via sciigilo efektive ricevis?

Stato kvar ekbruligas sciigon en unu API kaj signifas ion alian en alia, kaj la kodo tute ne montras diferencon. Ĉiu stata valoro en NetworkManager apartenas al nomita enumeracio, kaj la enumeracioj ne konsentas pri tio, kion signifas donita nombro. Kopii entjeron el funkcianta fragmento en alian retrovokon do ne estas transdono de konduto; ĝi estas koincido atendanta rompiĝi. Trovu unue la tipon, kaj la nombro fariĝas legebla.

Nombro sen tipo estas nur onidiro

Du enumeracioj gravas ĉi tie. Unu priskribas aktivan konekton ĝenerale: nekonata, aktiviganta, aktiva, malaktiviganta, malaktivigita. La alia priskribas specife VPN-konekton, kaj ĝi havas pli da haltoj survoje, inkluzive preparadon, agordon de la konekto, IP-agordon kaj aŭtentigan peton antaŭ ol io ajn aktiviĝas. Ilia numerado komenciĝas je nulo en ambaŭ kazoj kaj poste disiĝas, do la valoro signifanta malaktivigita en la ĝenerala enumeracio finiĝas ie meze de la VPN-sekvenco. Neniu el la kapoj malĝustas; ili respondas al malsamaj demandoj.

Uzu la simbolan konstanton el la instalita kapo aŭ bindado anstataŭ literalo. La nomo postvivas renumeradon; la entjero ne.

Observu unu konekton, ne la maŝinon

Komencu de la profila UUID, kiu interesas vin, kaj de la objekto de aktiva konekto kreita de tiu aktivigo. Stato de aparato, aŭ la stato de alia tunelo, ne estas anstataŭaĵo, eĉ kiam ambaŭ ŝanĝiĝas en la sama momento. Konservu la identecon de la objekto kun la observado, por ke posta raporto povu diri, kiu profilo produktis ĝin. La maŝino havas multajn statojn; la sciigo temas pri unu el ili.

Poste decidu, kion la sciigo devus signifi. Konekto, kiu neniam atingis aktivigon, estas agorda malsukceso, kaj sesio, kiu estis aktiva kaj poste malaperis, estas perdo. Tiuj meritas malsamajn vortojn.

Diru, kiun transiron vi raportas

Konservu la antaŭan staton kaj komparu ĝin kun la nova, anstataŭ testi la novan valoron izolite. Transiro en malsukcesan staton kaj transiro el aktiva stato estas malsamaj eventoj, eĉ kiam ambaŭ finiĝas kun nenio konektita. Notu la kaŭzan ĉenon apude, ĉar ĝi ofte estas la sola parto, pri kiu uzanto povas agi.

Intenca malkonekto ne estas fuŝo. Se la sciigo ne povas distingi, ĝi edukos homojn ignori ĝin.

Tenu la observanton viva

Ripeta enketado ne rajtas levi alian averton por stato, kiu ne ŝanĝiĝis. Tiu unu regulo forigas la plej grandan parton de la bruo, kiun tiuj sciigiloj produktas.

Traktu ankaŭ la kazon, kiam la administrilo restartas aŭ la observata objekto estas anstataŭigita. Observanto ligita al eksmoda identeco silentas ĝuste en la momento, kiam io interesa okazas, kaj silento aspektas kiel sano. Remalkovru la nunan objekton post ŝanĝo en la ĉeesto de la administrilo, kaj notu, kiam la remalkovro okazis. Alie la protokolo montras tunelon, kiu simple ĉesis raporti.

Liveru la sciigon tien, kie estas la uzanto

Privilegia sistema retrovoko ne heredas la sciigservon de labortabla sesio. Mesaĝo sendita de traktilo je radika nivelo povas malaperi sen eraro, kio produktas sciigilon, kiu funkcias kiam vi testas ĝin permane kaj neniam praktike. Liveru en la sesion, kiu posedas la labortablon, aŭ lasu la propran klienton de la labortablo levi la sciigon.

Preferu la ekzistantan sciigon de la kliento, se ĝi jam kovras la kazon, ĉar du sciigiloj por unu evento estas subtena problemo, ne redundo. Konservu la eventan tempon, la profilon kaj la kialon en la subtena rikordo, kaj lasu pasvortojn kaj plenajn profilojn ekster ĝi. Memoru, kio estas la sciigo: raporto pri observata stato, ne plenumiga mekanismo, ĉar bloki trafikon dum la tunelo forestas estas aparta politiko kun propra efektivigo.