Když sem začal psát mmarchitect, tak sem celou úlohu pojal zároveň jako studium jazyka
Vala. Ten se tváří jako alternativní implementace #C nebo Java. Ve skutečnosti jde o jakousi mezivrstvu k jazyku C, která ovšem programátorovi umožňuje mnoho zajímavých postupů. Co je ovšem na jazyku Vala specifického je jeho úzký vztah z
GObject. Tato vazba napovídá i mainstreamovou spolupráci s grafickou knihovnou
GTK+. No a to nás celé vede k multiplatformnosti tohoto jazyka včetně jeho různých rozšíření, nebo chcete-li, knihoven. Architecta sem od samého začátku psal jako aplikaci, kterou rozhodně budu chtít kompilovat na systému Windows a pokud bude mít úspěch, třeba si najde uživatele i na MacOS. (
Primárním vývojářským systémem je Linux).
S tím ale souvisí otázka z názvu tohoto článku, blogpostu. Co konfigurace, kam s ní. Na výběr jsou v podstatě dvě možné formy. První je textová. Známe ji z různých serverů ale i grafických aplikací. Oblíbené jsou
ini a conf soubory, vídané především z prostředí internetových serverů jako jsou apache, lighttpd, proftpd, postfix a jiné. Nebo také xml soubory, používané vedle různých systémových démonů také třeba v projektu Mono nebo .NET.
Druhou možností je použít registry. Někteří unixáci možná namítnou, že unix-like systémy nemají registry, to ale není tak úplně pravda. Gnome například používá systém xml struktur, které registry velmi připomínají a i když jsou z pohledu implementace zcela rozdílné, uživatelsky jsou v podstatě totéž. Navíc nově v Gnome 3 se nachází systém dconf, který v závislosti na backendu může být vlastně naprostou kopií registrů.
Jaké jsou tedy pro a proti ?
Vala, resp. glib nabízí hned několik možností. Jednak může číst ini soubory, ovšem přímo zápis sem nikde nenašel, ten však asi je to poslední co by dělalo problém. Po pársování conf souborů sem nepátral, a asi bych si ho musel sám implementovat, i tak by to asi nebyl takový problém. XML se snadno čte i zapisuje, navíc formát XML je i formát ve kterém jsou mapy z architecta uloženy.
Oproti tomu
gconf z Gnome 2.X zřejmě není úplně multiplatformní záležitostí na rozdíl od
dconf, který je ale až v Gnome 3.X. Proč zvolit gconf či dconf ? Existuje mnoho zajímavých vlastností, které tyto systémy umí. Hlavním důvodem je především to, že nová verze do systému nainstaluje nový config s novými hodnotami, ale Vaše konfigurace se to nijak nedotkne, pokud to není vysloveně žádoucí. Dále jsou tyto systémy velmi dobře připraveny do firemního prostředí, kde může administrátor i přes síť konfigurovat některá pravidla firemní kultury. Systém dconf má navíc krásnou vlastnost, a to že programátor může být zcela odstíněn od úložiště. To může být v podstatě cokoli, co si administrátor systému nastaví, takže v unixu to může být xml struktura, v MS Windows registry. (
Použití backendu lze ovlivnit systémovou proměnou, a některé backendy mají různá omezení v použití.)
Jiný úhel pohledu
Na tyto dva systémy se ale můžeme podívat i jinak. A to zda potřebujeme, aby konfigurace naší aplikace byla čitelná pro správce systému. Dalo by se říci, že pokud vytváříme nějakou serverovou aplikaci, je často velmi vhodné, aby konfigurace byla snadno editovatelná v textovém editoru. Není třeba zbytečně programovat nějaké konfigurační gui.
Na druhé straně v případě grafických aplikací, se konfigurační gui velmi hodí. Editovat nastavení nějakého grafického programu prostřednictvím editace textového souboru je velmi nepohodlné a rozhodně dávno přežité. Otázkou pak je, proč existují programy jako regedit, gconf-editor nebo dconf-editor. Právě pro manipulaci se skrytými konfiguračními parametry, nebo ke kontrole co se kde rozbilo, když se ten úžasný celý systém sesype.
Závěrem
Tento článek sem vlastně začal psát proto, abych si sám utřídil myšlenky co vlastně použít. A aby to bylo fér vůči textové konfiguraci, je třeba podotknout, že dconf i gconf vyžadují xml, popisující konfiguraci, tedy všechny její možnosti. To má samozřejmě i své výhody v momentě, kdy by se aplikace pokoušela ukládat nějakou nestandardní hodnotu.
Sám stále nevím pro jakou možnost se rozhodnu, ale i když se mě dconf systém líbí, pro začátek zřejmě bude snazší ukládat konfiguraci mé gui aplikace mmarchitect do nějakého xml souboru uloženého v domovském adresáři uživatele, s tím, že výchozí hodnoty si aplikace stejně nese sama v kódu, nebo použije systémové nastavení. Konfigurační systém dconf ale neopouštím a je dost možné, že ho budu paralelně implementovat. V konečné fázi ho třeba i použiji, nebo dám uživateli na výběr.
Na závěr bych chtěl napsat, že bych byl velmi rád, kdyby jste sami vyjádřili svůj názor a případně se podělili o své zkušenosti v diskuzi pod článkem. Myslím že touto otázkou se zabývá poměrně hodně programátorů, kteří nejsou hned se vším hotovi a návrh aplikace si raději 2x rozmyslí.