Ian Reinhart Geiser
geiseri at yahoo.com
Thu Jun 26 16:01:13 BST 2003
-----BEGIN PGP SIGNED MESSAGE-----
On Thursday 26 June 2003 10:25 am, Waldo Bastian wrote:
> On Thursday 26 June 2003 15:13, Ian Reinhart Geiser wrote:
> > Really KConfigBase should be avoided so we can continue to clean up the
> > API pre KDE 4.0. Currently the design ensures that we cannot have
> > multiple backends, and that its VERY VERY hard to keep multiple instances
> > of applications prefs in sync effectively.
> That's a missing feature, yes. But I don't think the design prohibits
> implementing it.
I do if we wish it to be remotely efficent.
> > Lucky due to waldo's awesome speed
> > hacks we dont notice this on the INI backend, but on my SQL backend I was
> > able to push my postgres server into a frenzy as it requerried the server
> > about 49 times in konqis start up :) (*note* this is because of
> > braindamages in how we do our standard dirs, and local stuff, not
> > neccicarily kconfig. If i hack my env down, i can get konqi startup to
> > only reparse KConfig files about 27-30 times. also when i say reparse, i
> > mean it calls the reparse config of an individual file. afaik we only
> > call reparse config everytime any stddir or resource is added... the
> > problem is the complexity grows as you add more files.)
> > LDAP was even worse, but that was because I made the mistake of doing
> > each key as an entry and not one file as an entry.
> At the time KConfig was designed the idea was that one could plugin other
> (e.g; SQL/LDAP) backends directly into KConfig. Personally I don't think
> that this is the way to go (too slow because too much roundtrip delay) and
> that the correct solution is to have a seperate sync-daemon that fetches,
> syncs and re-uploads (config-) files to the server and that applications
> basically keeps using the existing INI-file backend.
Yikes! NO... sounds like we are trying to come up with rube goldberg invetion
of the year here. Really what IMHO we need is to make each key in the
config entry map aware of what resource/file it camefrom and if its dirty,
maby even a refresh time on it. Then when we access an entry at that time
and only at that time is it checked to see if its dirty. I have
experimented with this already and was able to reduce the number of reparses
of the config files by a fair amount.
> Form there you could tweak things a little and instead of using the INI
> backend, write a backend that communicates directly with the sync-daemon,
> but I doubt that would gain you much. Such approach would be awefully close
> to GNOME's GConf btw.
i attempted something like this with dcop, but got problems since i think dcop
needs kconfig, or maby its not all started up yet... i really gave up on in
quickly because everything got trashed pretty quick. I thought about using
the shared memory approach, but i had a bugger of a time trying to dynamicly
allocate shared memory in a manner to store the entry map.
> Can you post your stats on the files that get parsed during konqy startup?
Here is what gets parse when konqi starts up in filemanager mode:
We reparse kdeglobals 12 times alone :)
Yeah we are busy little beavers at startup here :)
As you can see your friendly sysadmin will have your ass if you do this to his
LDAP or SQL server ;)
-ian reinhart geiser
- --:Ian Reinhart Geiser <geiseri at yahoo.com>
- --:Public Key: http://geiseri.myip.org/~geiseri/publickey.asc
- --:Public Calender: http://geiseri.myip.org/~geiseri/publicevents.ics
- --:Jabber: geiseri at geiseri.myip.org
- --:Be an optimist -- at least until they start moving animals in
- --: pairs to Cape Canaveral. ~ Source Unknown
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the kde-core-devel