Skip to content

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.

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

No comments

Add Comment

Markdown format allowed
Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
Form options