After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 172283 - XmlSerializer-based configuration system for beagle
XmlSerializer-based configuration system for beagle
Product: beagle
Classification: Other
Component: General
Other Linux
: Normal enhancement
: ---
Assigned To: Beagle Bugs
Beagle Bugs
Depends on:
Reported: 2005-03-31 18:26 UTC by Daniel Drake
Modified: 2005-06-02 18:19 UTC
See Also:
GNOME target: ---
GNOME version: ---

XML configuration system (35.80 KB, patch)
2005-03-31 18:27 UTC, Daniel Drake
none Details | Review
Basic GConf-based config system (26.19 KB, patch)
2005-04-14 22:07 UTC, Daniel Drake
none Details | Review
XmlSerializer-based config system (18.49 KB, patch)
2005-05-21 21:55 UTC, Daniel Drake
none Details | Review
XmlSerializer-based config system (35.92 KB, patch)
2005-05-22 17:26 UTC, Daniel Drake
none Details | Review
XmlSerializer-based config system (36.15 KB, patch)
2005-05-23 19:38 UTC, Daniel Drake
committed Details | Review
incremental (8.67 KB, patch)
2005-05-23 19:40 UTC, Daniel Drake
none Details | Review

Description Daniel Drake 2005-03-31 18:26:28 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.
Comment 1 Daniel Drake 2005-03-31 18:27:53 UTC
Created attachment 39518 [details] [review]
XML configuration system
Comment 2 Daniel Drake 2005-04-03 22:51:37 UTC
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.
Comment 3 Daniel Drake 2005-04-14 22:07:06 UTC
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.
Comment 4 Daniel Drake 2005-05-18 23:27:21 UTC
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.
Comment 5 Daniel Drake 2005-05-21 21:55:36 UTC
Created attachment 46730 [details] [review]
XmlSerializer-based config system

Here's the basic system so far. Right now it only supports "offline" adding of
Comment 6 Daniel Drake 2005-05-22 17:26:17 UTC
Created attachment 46752 [details] [review]
XmlSerializer-based config system

This is ready for review/commit. Any comments?
Comment 7 Joe Shaw 2005-05-23 18:08:42 UTC
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";
		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?)
Comment 8 Daniel Drake 2005-05-23 19:38:06 UTC
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.
Comment 9 Daniel Drake 2005-05-23 19:40:36 UTC
Created attachment 46816 [details] [review]

Incremental diff so that you can see what I've changed in the last update