GUI gegen TUI: Konsistenzprüfung
In einem auf Dateien basierenden TUI kann man mehrere Änderungen gleichzeitig durchführen, die dann mit der Aktivierung der neuen Konfigurationsdatei alle zusammen gleichzeitig aktiv werden. Während der Durchführung der Änderungen kann ein inkonsistenter Zustand bestehen, ohne dass er sich auf den laufenden Betrieb auswirkt.
In einem auf einer Kommandozeile basierenden TUI sind zwei Philsophien möglich: Entweder erwartet das System, dass der Administrator sicherstellt, dass die zwischendrin auftretenden Inkonsistenzen nicht fatal sind ("Du hast es so gewollt, da hast Du's"-Ansatz, siehe Cisco), oder es verhindert Inkonsistenzen durch Programmlogik ("you cannot delete option foo because it is still in use in option bar", was besonders bei mehrstufigen Abhängigkeiten der optionen untereinander bei so trivialen Dingen wie "ich möchte eine Accessliste umbenennen" zu massiver Mehrarbeit lösen kann, siehe auch Netscreen).
In einem GUI sind diese Paradigmen beide genauso möglich, wobei die meisten GUIs den zweiten, restriktiveren Ansatz verfolgen. Auch die Speicherung mehrerer Änderungen und deren gesammelte atomare Aktivierung ("Transaktionsfähigkeit") ist in GUIs möglich, aber eher selten implementiert.
Unentschieden, mit IMO leichtem Plus für das dateibasierende TUI wegen der aus dem Konzept inhärent folgenden Transaktionsfähigkeit.
Comments
Display comments as Linear | Threaded