Nem arrol van itt szo, hogy "dobjunk ki minden db megoldast a picsaba", hanem arrol, hogy sok kis fuggetlen "db" (oke, az nem db) vs 1 nagy db.
Amit a registry megnyer azon, hogy binarisan tarolja az adatot vs xml parse, azt elvesztheti azon, hogy minden alkalmazas obelole akar valamit kiolvasni mikozben irni is, mig az alapesetben lassabb xml-es plistet 1-2 process pingelgeti per (cache-elt) fajl. Minden mas esetben azt latom, hogy akkor hasznalnak DB megoldast, amikor mar elkerulhetetlen, hogy sokmindenki minden adatot lasson (pl. szerver oldalon RDBMS-ek), de mindenki azert torekszik arra, hogy a kulon egymastol fuggetlen adatbazisok kulonallok legyenek (tudom, tudom, tobb tera vs "parszaz mega", de akkor is). Registry-nel ott kezdodik a baj, hogy legutobb mikor neztem, a Windows-ra irt programok jelentos resze is olvasgatott belole es irt is bele boven. Olyanok, amiknek a beallitasait semmi mas nem fogja hasznalni. (De mint fentebb emlitettem, nem a Windows hibaja, hogy igy irnak ra programokat idonkent).
De ettol fugggetlenul tenyleg elgondolkodtato amit irsz. Viszont az is, hogy miert a Symantec-nek kellett kiadnia egy toolt, ami arra volt jo, hogy megoldotta, amit a Microsoft evtizedekig nem tudott hazon belul. Foleg, hogy mint irtad "mindig minden implementációt lehet jobbá tenni", nos, nem ugy tunik, hogy az MS-nek erre barmikor is tul nagy igenye volt. Meg ugy elso ranezesre is nekem a registry tipikusan annak a kodnak tunik a Windows-ban, amit egyszer valaki osszerakott, azt hitte majd 4-5 Windows komponens fog bele irni, es o maga se gondolta volna, nem is ugy tervezte, hogy majd ekkorara novi ki magat.
Szerk.: egyebkent a plist "nem csak egy sima XML", "egyenesen parse-olhato" az Objective-C NSArray es NSDictionary adatszerkezeteibe, de ettol meg termeszetesen meretben ott van az XML overheadje.