Ce stare NetworkManager a primit de fapt notificatorul tău?

Starea patru declanșează o notificare pe un API și înseamnă altceva pe altul, iar codul nu arată nicio diferență. Fiecare valoare de stare din NetworkManager aparține unei enumerări cu nume, iar enumerările nu sunt de acord cu privire la ce înseamnă un anumit număr. Prin urmare, copierea unui întreg dintr-un fragment funcțional într-un alt callback nu este un transfer de comportament; este o coincidență care așteaptă să se rupă. Găsește mai întâi tipul, și numărul devine lizibil.

Un număr fără tip este doar o vorbă

Aici contează două enumerări. Una descrie o conexiune activă în general: necunoscut, activare, activ, dezactivare, dezactivat. Cealaltă descrie specific o conexiune VPN și are mai multe opriri pe parcurs, inclusiv pregătirea, configurarea conexiunii, configurarea IP și o cerere de autentificare înainte ca ceva să fie activat. Numerotarea lor începe de la zero în ambele cazuri și apoi diverge, așa că valoarea care înseamnă dezactivat în enumerarea generală ajunge undeva la mijlocul secvenței VPN. Niciunul dintre antete nu este greșit; răspund la întrebări diferite.

Folosește constanta simbolică din antetul sau bindingul instalat în locul unui literal. Numele supraviețuiește unei renumerotări; întregul nu.

Urmărește o conexiune, nu mașina

Pornește de la UUID-ul profilului care te interesează și de la obiectul conexiunii active creat de acea activare. Starea unui dispozitiv, sau starea altui tunel, nu este un substitut, chiar și atunci când ambele se schimbă în același moment. Păstrează identitatea obiectului împreună cu observația, pentru ca un raport ulterior să poată spune ce profil l-a produs. Mașina are multe stări; notificarea este despre una dintre ele.

Apoi decide ce ar trebui să însemne notificarea. O conexiune care nu a ajuns niciodată la activare este o eroare de configurare, iar o sesiune care a fost activă și apoi a dispărut este o pierdere. Acestea merită cuvinte diferite.

Spune ce tranziție raportezi

Salvează starea anterioară și compară-o cu cea nouă, în loc să testezi valoarea nouă izolat. O tranziție către o stare eșuată și o tranziție din afara unei stări activate sunt evenimente diferite chiar și atunci când ambele se termină fără nimic conectat. Notează șirul motivului alături, pentru că adesea este singura parte pe care utilizatorul poate acționa.

O deconectare intenționată nu este o defecțiune. Dacă notificarea nu poate face diferența, îi va învăța pe oameni să o ignore.

Ține observatorul în viață

Interogarea repetată nu trebuie să ridice un alt avertisment pentru o stare care nu s-a schimbat. Acea singură regulă elimină cea mai mare parte a zgomotului pe care îl generează aceste notificatoare.

Gestionează și cazul în care managerul repornește sau obiectul observat este înlocuit. Un observator legat de o identitate învechită tace exact în momentul în care se întâmplă ceva interesant, iar tăcerea arată ca sănătate. Redescoperă obiectul curent după o schimbare în prezența managerului și notează când a avut loc redescoperirea. Altfel jurnalul arată un tunel care pur și simplu a încetat să raporteze.

Livrează notificarea acolo unde este utilizatorul

Un callback de sistem privilegiat nu moștenește serviciul de notificări al unei sesiuni de desktop. Un mesaj trimis dintr-un handler la nivel de root poate dispărea fără eroare, ceea ce produce un notificator care funcționează când este testat manual și niciodată în practică. Livrează în sesiunea care deține desktopul, sau lasă clientul propriu al desktopului să ridice notificarea.

Preferă notificarea existentă a clientului dacă acoperă deja cazul, deoarece două notificatoare pentru un eveniment sunt o problemă de suport, nu o redundanță. Păstrează ora evenimentului, profilul și motivul în înregistrarea de suport, și lasă parolele și profilurile complete în afara ei. Amintește-ți ce este notificarea: un raport despre o stare observată, nu un mecanism de aplicare, deoarece blocarea traficului în lipsa tunelului este o politică separată cu propria implementare.