GNOME Bugzilla – Bug 172283
XmlSerializer-based configuration system for beagle
Last modified: 2005-06-02 18:19:39 UTC
Here's something I've been working on while offline over the last few days: a configuration file for beagle. Right now you can only control which filename patterns are ignored, and which roots are indexed, but this will be extended to other things once the design is finalised. Here's how it works: - The config file is kept at ~/.beagle/config.xml - The config file is generated at first run by copying the default config which is installed to /usr/share - The config file is split up into sections under the main <beagle> node. Currently there is only one section: indexing - Util/Conf.cs (Beagle.Util.Conf) is the config file parser. It is designed to be able to be used without the beagle daemon running. It reads the configuration into various internal structures, and provides functionality for modifying the configuration and writing those changes back to disk. - On startup, the relevant parts of beagled (currently only FileSystemQueryable) hook themselves onto the UpdateHandler event. After the query drivers have started up, the config file is parsed. - Every time the config file is parsed, the UpdateHandler event is propogated. So when beagled starts up, the configuration comes into effect. - Beagle.Util.Conf can optionally watch the configuration file for updates using inotify. When an update is detected, the file is parsed again, and all UpdateHandler subscribers are notified. (beagled uses this feature) - There is a new RemoteControl dbus method which asks beagled to reload the config file. - There is a command line interface to Beagle.Util.Conf, called beagle-config. beagle-config allows execution of "section options" in Beagle.Util.Conf. For example, the indexing section provides an AddRoot section option. - After every section option is executed, beagle-config uses dbus to instruct beagled to reload the configuration file (it may have done this automatically with inotify, but it will only reload it if it has changed since the last reload) - beagle-config also provides a command line option to access the dbus ReloadConfig method, which will be useful for non-inotify users who update the configuration file "by hand" and then need some way of asking beagled to reread it. - There are a number of FIXMEs and other things still left to do, but I felt I should post my progress so far incase there are any big design issues.
Created attachment 39518 [details] [review] XML configuration system
Started working on converting this to GConf. I haven't got anything compilable yet, but I'll post a patch once I have the basics done.
Created attachment 45271 [details] [review] Basic GConf-based config system Here's some early code providing the basic GConf-based config functionality plus a command line interface. See inside for more description, and see planet beagle for even more info.
Can't get GConf working smoothly beyond reading the configuration. Next I'm going to try another XML-based scheme - Joe suggested storing the configuration as a class and then just serializing that to and from disk.
Created attachment 46730 [details] [review] XmlSerializer-based config system Here's the basic system so far. Right now it only supports "offline" adding of roots.
Created attachment 46752 [details] [review] XmlSerializer-based config system This is ready for review/commit. Any comments?
Great work Daniel. Some comments: * Lets create a ConfigException class instead of throwing System.Exception in various places. * IsMutator should probably be true by default, I would think. From your code it seems so from an empirical standpoint. * The output needs to be i18n friendly. That means no concatenating of strings. String.Format() is ok a lot of the time, but in the case of IndexHome(), it has to be something like: if (index_home_dir) output [0] = "Your home directory will be indexed"; else output [0] = "Your home directory will not be indexed"; * The methods marked by ConfigOption have a very awkward API, and I don't really understand it because all of the ones you have marked are pretty straightforward. Are the arrays to work around issues with MethodInfo.Invoke (which I'll get to later) or is the intention to have multiple outputs, etc? * I think you can do what you think you can't do with MethodInfo.Invoke(). I'd suggest changing the API for ConfigOption-marked methods to this: bool DoStuff (out string output, params object[] args); and then you can do something like this: MethodInfo method = t.GetType ().GetMethod ("DoStuff"); object[] morecrap = { "hello", 9, -0.99, DateTime.Now }; string s = null; object[] methodparams = { s, morecrap }; method.Invoke (t, methodparams); Console.WriteLine ("s: {0}", methodparams[0]); the local variable "s" won't change, but methodparams[0] will be set to whatever "output" is set to in the DoStuff() method. The API looks better and is more safe from code which might call it directly. (Speaking of which, does any? Do those methods need to be marked public? Could they just be private or internal?)
Created attachment 46815 [details] [review] XmlSerializer-based config system * Added ConfigException * IsMutator now true by default * Translatable strings fixed * ConfigOption methods used the ugly boxed array because I couldn't get method.Invoke () to work with "out" parameters .. I now realise that this is possible, so ConfigOptions have been simplified accordingly * GetMethod(string) requires the methods to be public, but GetMethod(string,BindingFlags) allows us more flexibility. It now searches for non-public invokable instance methods (and similar for GetMembers), plus the SectionOptions have been marked as internal.
Created attachment 46816 [details] [review] incremental Incremental diff so that you can see what I've changed in the last update