Open Source im professionellen Einsatz
Linux-Magazin 04/2001

Registrierdatenbank

Bitte hier anmelden!

Welcher Windows-Benutzer kennt sie nicht, die beliebte Registry, in der das System und diverse Programme die Konfigurationsdaten speichern - oder auch nicht, oder teilweise. Aber immerhin ist sie ganz einfach zu bedienen: mit der Maus. Es geht sogar noch ein bisschen einfacher.

1302

Wie immer soll alles - vollmundig versprochen - besser und schöner werden. Diesmal geht es um die Möglichkeit, Konfigurationsdaten für Programme an einer einzigen zentralen Stelle zu speichern, zu verwalten und bei Bedarf abzufragen, beispielsweise beim Programmstart. Die Gnome-Entwickler haben begonnen dafür einen Mechanismus an den Start zu bringen, dem sie den Namen GConf gegeben haben.

GConf soll in der Version 2.0 von Gnome vollständig Einzug halten, liegt aber in einem Paket schon im Unstable-Tree des Quellcodes vor. Einige neue Programme, zum Beispiel Nautilus und Evolution, verlangen bei ihrer Kompilierung bereits jetzt nach GConf. Die Bibliothek soll jedoch nicht auf Gnome beschränkt bleiben, sondern sich letztlich auch für reine Gtk+- und X-Applikationen, KDE-Programme und sogar von der Kommandozeile aus verwenden lassen.

Laut Havoc Pennington in [1] - einem Artikel, an den ich mich im Folgenden stark anlehnen werde - steckt Gnome, was die Konfiguration von Applikationen betrifft, im Stadium von Windows 3.x, weil jedes Programm seine eigenen Einstellungen in separaten Dateien ablegt. Mit der Registrierungsdatenbank unter Win9x sei ein schlauer Schritt vollzogen worden, allerdings mit diversen Einschränkungen:

Dem Artikel zufolge möchte GConf mit einem zweischienigen System sowohl eine Bibliothek als auch eine Architektur zur Verfügung stellen, was sich wie folgt gestalten soll.

Das Konzept

In der Theorie soll GConf einen Haufen Vorteile bieten, wenn es erst mal fertig und ausgereift ist. So ist das eben: Wir reden von freier Software im Anfangsstadium mit erheblichen Ansprüchen an das, was einmal werden soll.

Das beginnt bei der Unabhängigkeit vom Back-End, in dem die eigentlichen Daten gespeichert werden sollen. Die aktuelle Implementation speichert alles in XML-Dateien ab, die sich natürlich, wenn man nur von Files ausgeht, für hierarchische Organisationen am besten eignen.

Model - View - Controller (MVC)

Dieses dreistufige Konzept besteht aus einem Modell (Model), einer oder mehreren darauf ausgerichteten Ansichten (Views) und schließlich einem oder mehreren Controllern (wofür ich keine gute Übersetzung habe). Diese Teile erfüllen die folgenden Aufgaben:

  • In einem Modell wird die Struktur der Daten konzipiert. Für GConf bedeutet das zum einen, die ganze Datenbank zu konzipieren, und zum anderen, im Detail sich Gedanken über die Schlüssel zu machen, die vorhanden sein sollen.
  • Eine View ist eine bestimmte Ansicht der Daten. Diese View kann dem Modell entsprechen, indem einfach alle Daten zugänglich gemacht werden, oder - und das dürfte meist der Fall sein - es wird ein bestimmter Ausschnitt dargestellt. Wann immer sich das Modell ändert, müssen auch die Views angepasst werden.
  • Mit einem Controller lassen sich die Daten schließlich von außen verändern.

Aber auch ein binäres Format soll möglich sein wie bei der Registry, und wer richtig loslegen möchte, kann den Zugriff auch über LDAP oder sogar eine SQL-Datenbank seiner Wahl regeln. Die Idee dahinter ist, dass sich der Administrator eines Netzwerks ganz einfach das aussuchen kann, was ihm am besten in seine Infrastruktur passt.

Listing 1: Der Client

1: 
2: #include <gconf/gconf-client.h>
3: #include <gtk/gtk.h>
4: 
5: void callback (GtkWidget* entry, gpointer user_data)
6: {
7:   GConfClient *gclient;
8:   gchar       *str;
9:   
10:   client = GCONF_CLIENT (user_data);
11: 
12:   str = gtk_editable_get_chars (GTK_EDITABLE (entry), 0, -1);
13: 
14:   gconf_client_set_string (client, "/extra/de/derfrosch/linux-magazin/gconf", str, NULL);
15: 
16:   g_free(str);
17: }
18: 
19: int main(int argc, char *argv [])
20: {
21:   GtkWidget   *fenster;
22:   GtkWidget   *entry;
23:   GConfClient *gclient;
24: 
25:   gtk_init (&argc, &argv);
26:   gconf_init (argc, argv, NULL);
27:   
28:   fenster = gtk_window_new (GTK_WINDOW_TOPLEVEL);
29:   entry = gtk_entry_new ();
30: 
31:  gtk_container_add (GTK_CONTAINER (fenster), entry);  
32: 
33:  gclient = gconf_client_new ();
34: 
35:  gconf_client_add_dir (gclient, "/extra/de/derfrosch/linux-magazin/gconf", GCONF_CLIENT_PRELOAD_NONE, NULL);
36: 
37:  gtk_signal_connect (GTK_OBJECT (entry), "activate", GTK_SIGNAL_FUNC (callback), gclient);
38:   
39:  gtk_widget_show_all (fenster);
40: 
41:  gtk_main();
42: 
43:  return 0;
44: }

Die einzelnen Keys - es werden ähnlich wie bei der Registry Daten in Schlüssel/Werte-Paaren gespeichert - sollen je ein eigenes Feld zur Dokumentation erhalten, das dann durch eine Applikation, mit der sich die Werte verändern lassen, dargestellt wird. Zusätzlich sollen weitere Informationen zu speichern sein, beispielsweise wann der Schlüssel das letzte Mal geändert wurde. Aus der bisherigen Dokumentation ist nicht zu ersehen, ob vielleicht ein Mechanismus vorgesehen ist, der das Editieren bestimmter Keys verhindern oder privilegieren kann.

Außerdem soll es einen Data Notification Service geben. In der Zeit der Komponenten, in der jedes Programm mit jedem anderen kommunizieren kann, ist es sinnvoll, Änderungen im Netzwerk so zu propagieren, dass alle Applikationen, bei denen das gewünscht ist, sich entsprechend umkonfigurieren.

Dieses Konzept ist auch deshalb interessant, weil man auf diese Weise laufende Programme umgestalten kann. Beispielsweise mit einer Einstellung, die festlegt, dass alle Toolbars keine Icons mehr zeigen sollen, und dafür sorgt, dass diese Änderung sofort in allen Programmen Gestalt annimmt. Ich weiß allerdings nicht, ob ich der Einzige bin, für den sich das nach einem äußerst interessanten Ansatzpunkt dafür anhört, ein ganzes Netzwerk von Rechnern empfindlich zu stören.

Eine von Anfang an gut durchdachte API - also das Gegenteil zu dem, was im Moment bei Bonobo betrieben wird - und zusätzliche Details wie ein sinnvolles Locking sollen das Ganze abrunden.

Da lediglich Schlüssel/Werte-Paare gespeichert werden sollen, handelt sich auch nicht wirklich um eine Datenbank. Jeder Schlüssel hat wie unter Windows einen eindeutigen Namen. Um die Hierarchie darzustellen, wird ein System benutzt, das an das Dateisystem unter Unix erinnert: ein Schlüssel könnte zum Beispiel /programme/editor/fenster/schriftart heißen. Die Werte sind typisiert, werden also bereits vorher zum Beispiel als String, Integer oder durch einen anderen Datentyp festgelegt.

Listing 2: Der Controller

1: #include <gconf/gconf-client.h>
2: #include <gtk/gtk.h>
3: 
4: void callback (GConfClient* client, guint cnxn_id, const gchar* key, GConfValue* value, gboolean is_default, gpointer user_data)
5: {
6:   GtkWidget *label;
7:   
8:   label = GTK_WIDGET (user_data);
9: 
10:   if (value == NULL)
11:   {
12:     gtk_label_set(GTK_LABEL(label), " leer ");
13:   } else {
14:     if (value->type == GCONF_VALUE_STRING)
15:     {
16:       gtk_label_set (GTK_LABEL (label), gconf_value_string(value));
17:     } else {
18:       gtk_label_set (GTK_LABEL (label), " falscher Typ! ");
19:     }
20:   }
21: }
22: 
23: int main(int argc, char *argv [])
24: {
25:   GtkWidget   *fenster;
26:   GtkWidget   *label;
27:   GConfClient *gclient;
28:   gchar       *str;
29:   
30:   gtk_init (&argc, &argv);
31:   gconf_init (argc, argv, NULL);
32: 
33:   gclient = gconf_client_new();
34:   fenster = gtk_window_new (GTK_WINDOW_TOPLEVEL);
35: 
36:   str = gconf_client_get_string (gclient, "/extra/de/derfrosch/linux-magazin/gconf", NULL);
37:   
38:   if (str)
39:   {
40:     label = gtk_label_new (" leer ");
41:   } else {
42:     label = gtk_label_new (str);
43:   }
44: 
45:   if (str)
46:   {
47:     g_free (str);
48:   }
49:   
50:   gtk_container_add (GTK_CONTAINER (fenster), label);
51: 
52:   gconf_client_add_dir (gclient, "/extra/de/derfrosch/linux-magazin", GCONF_CLIENT_PRELOAD_NONE, NULL);
53:   gconf_client_notify_add (gclient, "/extra/de/derfrosch/linux-magazin/gconf", callback, label, NULL, NULL);
54:   
55:   gtk_widget_show_all (fenster);
56: 
57:   gtk_main();
58: 
59:   return 0;
60: }

Ein Dämon und mehr

Um GConf benutzen zu können, muss eine Dämon mit dem Namen Gconfd laufen. Es soll immer genau einen Dämon pro Benutzer geben, der sich über CORBA mit Applikationen verständigen kann.

Eine wichtiger Grad Abstraktion, der zum Beispiel auch bei einigen Widgets in der Gnome Application Library zum Tragen kommt, trägt den Namen MVC. Sein Konzept wird im Kasten "Model - View - Controller" näher erläutert.

Es gibt einige verschiedene Datentypen, mit denen man bei GConf herumhantieren kann. Es sind: GConfEngine, worüber eine Konfigurationsdatenbank angesprochen wird. In den meisten Fällen handelt es sich dabei um die Verbindung zu einem laufenden Gconfd-Dämon. Hinzu kommen GConfValue, eine Struktur, die die typisierten Werte aus einem Schlüssel/Werte-Paar kapselt, sowie GConfClient, ein Client, der mit einer GConfEngine kommunizieren kann, zudem diverse kleine Schmankerln wie Caching und schließlich GConfError, eine Struktur, mit der sich Fehler handhaben lassen.

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Kleine Mahlzeit

    Es muss nicht immer ein ausgewachsenes Programm sein. Viele kleine Aufgaben lassen sich auch mit Applets erledigen, die im Panel residieren und nur darauf warten, aufgerufen zu werden.

  • Spurensuche

    Der Desktop mit der Pfote findet auch hierzulande immer mehr Anhänger. Damit wächst die Bedeutung von Gnome als Entwicklungsplattform, deren GUI-Toolkit GTK sogar auf Windows und Mac läuft. Dieser Artikel verhilft zur Orientierung auf den verschlungenen Entwicklungswegen.

  • Schnellstart

    Das Mac-Utility Spotlight führt selbst hartgesottene Apple-Fanboys von der Maus wieder zurück zur Tastatur. Ein kurzes Perl-Skript implementiert das praktische Utility für den Linux-Desktop nach.

  • Käfige nach Maß

    Öffentlich zugängliche PCs sollen meist nur einem bestimmten Zweck dienen, große Funktionsvielfalt ist dabei eher hinderlich. Wie die KDE-Kollegen mit dem Kiosk-Modus sperren seit Version 2.14 des Desktops auch Gnome-Admins ihre Benutzer in einen goldenen Käfig.

  • SE-Linux-Sandbox für unsichere Programme

    Das Sicherheits-Framework SE Linux bietet künftig auch einen Sandkasten (Sandbox), in dem nicht-sichere Applikationen abgeschottet von anderen Systembereichen ausgeführt werden können.

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.