huzzah! kde 3.5.1 was released. congrats to all involved!
after a bit of hacking with tridge this evening, popping kde configs into ldb/tdb is down to comparable speeds with kconfig and even beating it by a slight margin at times if one turns off fsync and does per-file transactions. with fsync and per-file transactions (a.k.a. safe mode) it's hovering around the same speed, usually a tad slower though. this is a marked improvement over yesterday, to say the least.
tridge is looking at a few cases of inefficiency stemming from link list usage in the transaction code.
this is all on write. read is the next beast to tackle. and that requires revisiting kconfig itself quite a bit. i got an email from thomas braxton tonight who apparently has also been working on that particular area so we're going to combine efforts to bring the promise of multiple-backends for kconfig into reality.
i realized the other day that to do it Right, we'll have to provide for different backends based on resource type (which kconfig thankfully is already aware of) so that, for instance, application .desktop files always use the INI backend; we'll also have to provide a way to configure individual config prefixes, so that system configs can be rolled out over the network as single files using replication but users can continue to use INI files. i haven't really thought much about how to accomplish the latter; maybe thomas has ... or maybe i'll have to take a few extra showers in the coming days.
(i do my best thinking in the shower. warmth, water, white noise, gentle masssaging of the skin, nakedness. what could be more hospitable to deep thought?)
Subscribe to:
Post Comments (Atom)
3 comments:
I do my best thinking in the shower too.
One thing that has bothered me about the ~/.kde tree is that some files contain both configuration settings and other constantly changing data that I couldn't care less about. My motivation is that I keep my ~/.kde directory in subversion. I don't want my checkins cluttered with changes caused by visiting a link in my bookmarks, or noting the fact that kalarm ran and did nothing _again_.
One change that I would really like to see is the separation of the ~/.kde directory into the equivalent of /etc and /var Is this a reasonable goal for KConfig?
The easiest way to decide which app stores its config in ini is to ask the app itself. Or, have it set in the app's settings dialog. Alternatively, decide for it based on some simple "ini-worthy" algorithm.
I. DEFAULT BEHAVIOR
0. Assume ldb is ever-present and can be relied upon. Assume ini files are mostly for "backup" or "walk-around" function. Then:
1. Make ldb the default config storage. (For the case when app doesn't know how to ask otherwise.)
2. Suggest to developers of applications that may benefit from ini config storage that they implement one more config setting for choosing to "backup" each config change to the ini file (in addition to writing it to ldb (or, maybe only write it to ini only, only leaving a "see ini" flag in ldb (unchanged? no need to write to ldb)). Also, ask them to chose the sane default value, so the users don't have to think about it up-front. (For example, I would like Kmail, Kopete and similar config-intensive apps to "backup" setting to ini by default. I could care less about loosing Calculator's or SuperKaramba's settings, so, NO "backup" to ini file by default.)
3. If the "see ini" flag / full-fledged settings do not exist in ldb, the ini file is considered non-existent. It is never parsed / asked for directly, automatically on system startup, or even on app start up.
3. Store the "see ini / back-ed up" flag entry in ldb AND in ini (but (in special cases / always) ini gets priority if value is suddenly different. More on this in "Special Cases" section.). "backed up" entry in ldb is the first place where KDE looks and gets there from:
- app sets it on the 1st run.
- user sets it through settings dialog
- system sets it itself, automatically on initial user config, based on some sane app-class tree (This is possible future direction. This will override I.1. above.
- On "Restore System Config" event (called manually, or automatically on initial user configuration) by something like "kconfig --discover-new-ini-files" At which point ~/.kde is parsed for all ini files and incorporates/overwrites the changes into ldb. More in "Restore System" section
II. RESTORE SYSTEM
1. ldb is pushed to user from above.
a. See I.3. above.
b. User can incorporate his own ini files through "kconfig --discover-new-ini-files" if policy allows it.
2. Clean Install
a. User is asked if he wants to look for old settings (stored on a remove server / CD / old partition etc.) and incorporate them into this system. Ask to import "priority/selected-as-important" settings (meaning INI files only) or "everything under the sun" (ini and all the trash from ldb). At which point the wizard calls "kconfig --discover-new-ini-files" for that location.
b. Otherwise see "Default Behavior"
3. Restoring settings on already config-littered system
a. Can only be called manually
b. See "Special Cases":Flag priority
III. SPECIAL CASES
- may choose/prefer backup ALL of config in ini files for reliability and granularity.
- Flag priorities when it comes to importing settings from ini files: (ini always takes priority)
a. ldb "see ini" = 1 ini "see ini" =1 > ldb unchaged
b. ldb "see ini" = 1 ini "see ini" =0 > ldb chaged to "see ini"=0
a. ldb "see ini" = 0 ini "see ini" =1 > ldb chaged to "see ini"=1
a. ldb "see ini" = 0 ini "see ini" =0 > ldb unchaged
well, we can't really ask the app since the app should not needknow and at different levels in the $KDEDIRS hierarchy it may be different. and we can't store it in it's configuration as that leaves us with a bootstrap problem that's not particularly pretty.
right now i'm thinking a simple set of env vars that mimic $KDEDIRS might do the trick nicely.
yes, we'll have a fallback. but it probably won't be LDB; it'll likely be INI since if you don't know about LDB you probably don't need it.
we may ship with a configuration that uses LDB for `kde-config --prefix` as i suspect we'll get better performance out of LDB in a "cold disks" situation (e.g. first log in).
there's also the issue of different types of resources. for now we'll probably on care about restype="config" for now and leave the rest at INI until further notice.
i also feel that mixing different configuration backends in the same config/ directory is rather ugly: you'd have to search around to find out where the settings are amongst the different storage formats. ugh.
and any thing that relies on individual app developers to do something other than develop the features specific to their app's domain is just asking for inconsistency. we've learned that time and again =)
Post a Comment