Vlákno názorů k článku Linuxu chybí univerzální konfigurační systém od mj - Preco by mali byt konfiguraky v XML? Co...
-
XML je více formalizované. Co musím udělat, když chci upravit textový konfigurák? Musím si přečíst manuál a zjistit, jak se to píše. Neudělal jsem tam chybu? Musím (většinou) spustit daný program a ten buď spadne nebo ne. Pokud nespadne, ještě to neznamená, že je všechno OK, možná je v konfiguraci chyba a jen se zatím neprojevila. U XML se místo do manuálu podívám do XML schématu, tím, že je to více formalizované (metadata), můžou s XML lépe pracovat automatizované nástroje. Rovněž je možné zkontrolovat správnost konfiguračního souboru pomocí validátoru - nemusím spouštět aplikaci a čekat, jestli spadne/nespadne.
"Parser na jednoduchy plaintext sa da napisat prehladne na par riadkov."
Zatímco parser na XML nemusíš psát, protože už je hotový. Co je to plaintext za formát? CSV? Nebo tvar klíč=hodnota? Nebo tvar klíč:hodnota? Jak se oddělují skupiny atributů? Pomocí [skupina] nebo snad <skupina> Jak tam vyjádřím složitější struktury? -
mj (neregistrovaný)"Co musím udělat, když chci upravit textový konfigurák?" -> vi /etc/konfigurak
"Musím si přečíst manuál a zjistit, jak se to píše." -> Ano, je na tom nieco zle? Alebo pristup: nic o tom neviem, ani nechcem, ale mam velke ego, tak to spravim; je teraz velke pozitivum? Navyse byvaju v konfigurakoch aj poznamky.
"Zatímco parser na XML nemusíš psát, protože už je hotový." -> Pouzitie fread mi stale vychadza jednoduchsie, ako xml kniznice. Keby xml prinasalo tolko vyhod, tak uz su vsetky konfiguraky v xml, dvakrat. -
"Ano, je na tom nieco zle?"
Ano je - v manuálu nejsou informace formalizované, je to jen text, který dokáže interpretovat jen (inteligentní) člověk (nikoli stroj). Jak se tam zapíše, že proměnná foo může nabývat pouze hodnot JEDNA, DVA a TŘI? Tím, že do manuálu napíšeme: "bla bla bla, sem pište jenom JEDNA nebo DVA nebo TŘI, jinak vám to nebude fungovat bla bla bla". Zatímco v XML bude tento výčet formalizovaný a editor mi ani nedovolí zadat nepřípustnou hodnotu. Rovněž komentáře můžou být kontextové, vztahovat se ke konkrétní položce. A to takovým způsobem, že bude tyto informace možné zpracovávat automatizovaně (díky tomu budou moci vzniknout inteligentní editory nastavení)
"Ano, je na tom nieco zle? Alebo pristup: nic o tom neviem, ani nechcem, ale mam velke ego, tak to spravim"
I editace konfiguračního souboru může být intuitivní - co je špatného na tom, když mi editor bude nabízet pouze smysluplné hodnoty? Když nebudu muset půl hodiny studovat manuál, abych mohl něco nastavit?
(někdy mi přijde, že problém je spíše u těch jedinců, kteří si svoje ego staví na faktu, že sedí před černou obrazovkou, kde buší jako vzteklá opice něco do VIMu a nikdo kolem nich neví, co dělají, ano, pak si připadá jako guru. Vypadá to děsně kůl a skoro jako magie, ale mě zajímá spíš výsledek, než jak při tom vypadám ;-)
"Keby xml prinasalo tolko vyhod, tak uz su vsetky konfiguraky v xml, dvakrat."
XML přináší výhody, ale musím připustit, že to není zadarmo - předělat stávající software tak, aby místo prostých textových souborů používal striktně strukturované XML, stojí hodně práce. A někdy ta práce může být vyšší než ten užitek. Takže toto je důvod - u starých programů to prostě často nestojí za tu námahu. Ale to neznamená, že bychom se neměli zabývat nějakou vizí, jak to může být lepší. I dnes vznikají nové programy a u nich je XML (plus případně nastavení uložené v databázi) jasnou volbou. Konfiguráky ve starém stylu by dnes použil leda zapšklý zpátečník :-)
A protože se dnes používají XML konfigurační soubory, bylo by fajn, kdyby existoval standardní způsob, jak na základě schématu generovat GUI, nebo jak zapsat dodatečná metadata, která definují, jak se má GUI (případně jiné UI) pro editaci nastavení vykreslit. -
Narazil jste na to. Pro stávající NEGUI aplikace se nevyplatí přecházet na nové konfiguráky. Znám pořádně jen Postgres a tam je konfigurace +/- stabilní 10 let. Konfigurák sám v sobě obsahuje komentáře, varianty - tj. metadata. Většina stávajících serverů má validační režim, tj. nemusíte restartovat server, ale jen se zeptáte jestli je aktuální konfigurace správná. Nevidím důvod proč přecházet na novou syntax. A nejde o lenost programátorů, přepsat parser je práce na dva dny.
GUI aplikace ale většinou už konfiguráky v xml mají. Podívejte se do ./gnome2 adresáře. Některé včetně metadat. -
Je to tak, u zaběhnutých věcí, jako je třeba PostgreSQL to za to nestojí. Ale IMHO by bylo fajn mít nějakou vizi s tím, že nové programy budou moci používat nějaký jednotný framework, který by zajistil to překrývání uživatelským nastavením, validaci (aby si ji každý autor aplikace nemusel psát znova), verzování, případně generování GUI (což je to poslení). Místo generování GUI by stačilo mít slušný XML editor - nabízel by nám vhodné hodnoty, kontroloval syntaxi, napovídal... a byl by použitelný pro úpravu nastavení všech programů.
-
a) XML se poměrně obtížně ručně edituje, pokud se nepoužije speciální editor. Proto se pro konfiguraci nijak zvlášť neuchytil - přínos XML je hlavně v tom, že může obsahovat n zanořených sekcí, to má někdy smysl - a tam se XML už docela používá.
b) To, co lze validovat v XML je pro konfiguraci relativně nedostačující, nehledě na o, že z XML parseru vyleze pouze hláška, že tam či jinde je syntaktická chyba, případně že nesedí vůči DTD. Zkuste ladit DocBook dokument.
Ale souhlasím s tím, že by klidně metadata o konfiguraci + validační skripty byly v nějakém XML souboru. Nějaká univerzální vrstva nad konfiguráky by vůbec neškodila. Podobně jako např. existují package files pro knihovny. Pak bych mohl mít konfiguraci, tam kde to je pro danou distribuci výhodné a zároveň bych mohl vytvářet sofistikovanější nástroje - např. virtuální souborový systém pro konfigurace, který by mohl fungovat na všech distribucích. V jádře je to vyřešené skoro podobně. Máte příšerné konfiguráky, nicméně existuje mapování do proc s kterým se pak pracuje bezvadně. -
"XML se poměrně obtížně ručně edituje, pokud se nepoužije speciální editor."
Pokud se jedno o konfigurák typu klíč=hodnota, tak v XML místo toho musím psát <klíč>hodnota</klíč>. Uznávám, že je to pracnější, ne však složitější.
Pokud se ale jedná o více strukturovaný dokument, bude se správce v prostém textovém souborů těžko orientovat. V XML sice taky, ale může si vzít na pomoc editor, který mu s tím pomůže (třeba i ten "oblíbený" vim http://www.pinkjuice.com/howto/vimxml/)
"To, co lze validovat v XML je pro konfiguraci relativně nedostačující"
Není jen DTD, existuje i podstatně mocnější XML Schema. -
mity (neregistrovaný)Kdyz ta konfigurovana vec je jednoducha (zadna rekurze apod. jako napr. per-directory konfigurace u apache), tak je XML zbytecny overhead. Brani mi pouzivat jednoduse grep, sed atd., protoze klic je treba na jinem radku nez hodnota. Nebo dokonce na jednom radku muze byt mnohem vic klicu i hodnot (vlastne cele XML muze byt jednoradkove), takze ani pouziti editoru (napr. vi) nemusi byt jednoduche. Ano, jsou i editory pro XML -- ale uvazte, ze muzu byt pripojen vzdalene pres velmi pomalou linku a mam jen omezenou moznost instalovat novy SW na server, kde chci/musim neco konfigurovat.
Jestlize vy tak milujete XML, fajn -- napiste si sadu XSLT transformaci, a ty obycejne textove konfiguraky generujte z XML.
Ja chci jednoduche veci delat jednoduse. Kdyz se chci poskrabat na obliceji, tak to udelam rukou. Po skrabatku sahnu, az se budu chtit poskrabat na zadech. -
"takze ani pouziti editoru (napr. vi) nemusi byt jednoduche."
na tom něco je...
"Brani mi pouzivat jednoduse grep, sed atd., protoze klic je treba na jinem radku nez hodnota."
Otázka je, jestli nástroje mají sloužit nám, nebo mi jim. Proč bychom se měli omezovat tím, že máme starou lopatu? Tak si vezmeme novou a budeme pracovat novým způsobem :-)
"Jestlize vy tak milujete XML, fajn -- napiste si sadu XSLT transformaci, a ty obycejne textove konfiguraky generujte z XML."
Něco podobného mě napadlo - mohl by to být virtuální souborový systém /etc, který by se generoval z XML souborů. S tím, že časem by se programy naučily pracovat přímo s těmi XML soubory. Bohužel práce je moc a volný čas trávím raději s projekty, které mi připadají užitečnější - a taky uživatel vidí hned výsledky. -
anonymníto je proste proto ze na jednu stranu jsou uzivatele a admini linuxu pomerne pokrokovi, ale na druhou stranu jsou to konzervy, ktere brzdi leta zabehnay system
linux vznikl v urcite dobe, kdy soudobe stroje na neco stacily
stacily tak na praci s textovymi soubory proto bylo vse textove
a protoze se s nimi nepracuje snadno vznikla spousta pomucek ulehcujicich praci s nimi jako prave sed, grep atp.
co ale linuxove komunite brani napsat si xsed, xgrep a spoustu dalsich x veci?
xml a textaky je neco jako standardni programovani a objekty - objekty jsou pomalejsi, narocnejsi, slozitejsi, ale jsou univerzalni znovu pouzitelne a umozni vam pracovat na mnohem narocnejsich ulohach - ano program stejne urovne slozitosti bude nejspis efektivnejsi bez nich, ale vyse se dostanetejenom tezko -
Rejpal (neregistrovaný)
"xml a textaky je neco jako standardni programovani a objekty - objekty jsou pomalejsi, narocnejsi, slozitejsi, ale jsou univerzalni znovu pouzitelne a umozni vam pracovat na mnohem narocnejsich ulohach - ano program stejne urovne slozitosti bude nejspis efektivnejsi bez nich, ale vyse se dostanetejenom tezko"
"Objekty" bych do toho netahal, a už vůbec ne tímhle způsobem, takhle to vyznívá, že existuje nějaká jednorozměrná stupnice kvality programovacích technik a "objekty" jsou na ní výše a cokoli ostatní níže, což asi nemusí být nezbytně pravda, že. :-) Navíc opravdové objektové jazyky (jsou v zásadě jen dva) se dneska stejně moc nepoužívají. -
anonymníto z toho vyzniva? tam neni o kvalite ani slovo.
ja tvrdim ze diky vyssi urovni abstrakce je mozne se stejnymi (lidskymi) naklady resit ulohy vyssi slozitosti
a to neplati jenom u objektu, ale i treba u asm a vyssich jazyku nebo obecne u cehokoliv na bazi vrstevnate architektury
nemusite se proste az tak starat o detaily "na nizsich vrstvach" (fyzicke ulozeni dat, zpracovani, ovladace zarizeni, ...) a pracujete na nejvysi mozne urovni, ktere odpovida vas problem
chci pracovat s konfiguraci tj. nejakou datovou strukturou pro ulozeni nastavenych hodnot, v teto chvili mne nezajima jeji fyzicke ulozeni ani parsovani, jde mi o obsah ci spise vyznam -
MikRom (neregistrovaný)To XML je celkom dobry napad, ale hodilo by sa to viac na MS Windows.
Myslim, ze by bolo zaujimave mat registre ulozene vo forme XML. Lahsie by sa to odzalohovalo a bolo by mozne robit zmeny aj textovym editorom.
V UNIXe je to podla mna tak dobre ako je doteraz zauzivane - konfiguracia v textovych suboroch. -
problem neni virtualni souborovy system, ten uz existuje FUSE. Dokonce existuje i virtualni souborovy system zalozeny na databazi .. na jednom takovem jsem se podilel. Jde o to, ze pokud nenastartuje databaze obsahujici konfigurace, tak nenastartuje zadna aplikace a v Unixu v podstate budete mit kernel, a nebudete mit vubec nic. Kdezto plain soubor je jednoduse citelny a v podstate se na nem nema co rozbit. Navic jadro dokaze soubor precist za prakticky libovolne konfigurace, i chybne. Takze pokud udelate chybu, tak ji muzete opravit. Pokud by z nejakeho duvodu nenastartoval db server, tak uz hlavne nedokazete zmenit konfiguraci, jelikoz ji nemate kam zapsat - reseni postavene nad databazi sice nepostrada eleganci a jednotnost, ale neni odolne vuci chybam.
-
Sten (neregistrovaný)XML je výborný jazyk pro popis, co ten konfigurák může obsahovat. Samotná konfigurace by v XML nebyla (je to naprostá zbytečnost, která by běh zpomalovala a zvyšovala nároky na paměť), ale všechny možnosti by mohly být popsány v XML a jednotlivé konfigurační nástroje by pak neměly problém zjistit, co tam vlastně může být. Tím by se řešila i validace.
Plaintext nemá žádný formát. Nejčastější formát bývá INI. Složitější struktury než [sekce, klíč, hodnota] se tam nedělají (protože rozumně napsaná aplikace je stejně nepotřebuje). -
1) složitější struktury někdy potřeba jsou (ale to lze obejít - líbí se mi třeba aplikace, které mají v konfiguračním souboru jediný parametr: připojovací řetězec k DB. A všechno nastavení se pak už dělá v SQL).
2) Nejde jen o strukturovanost, ale i o takové "maličkosti", jako jsou parametry obsahující zalomení řádku, zvláštní znaky...
3) "XML je výborný jazyk pro popis, co ten konfigurák může obsahovat. Samotná konfigurace by v XML nebyla"
To by se musel dohodnout nějaký nový formát, který budou používat všichni, třeba:
[sekce]
klíč=hodnota
...
[jiná sekce]
...
Ale: proč vynalézat nové kolo, když už jedno máme (xml)? A když už přecházíme na nový formát, proč nepoužít rovnou ten, který nám bude dobře sloužit ještě dlouho a nenarazíme hned zítra na jeho limity (pouze jedna úroveň sekce, problém s escapováním, víceřádkovými parametry...)
ČLÁNKY DO MAILU