Subject: Re: XML config file
To: Jason Thorpe <email@example.com>
From: Iain Hibbert <firstname.lastname@example.org>
Date: 07/22/2006 10:10:50
On Fri, 21 Jul 2006, Jason Thorpe wrote:
> On Jul 21, 2006, at 1:46 PM, Iain Hibbert wrote:
> > On Tue, 4 Jul 2006, Jason Thorpe wrote:
> > > ...and we can do this now, with proplib.
> > Ok, I've started using some proplib functions for passing information to
> > and from the kernel and I like it so far. Is there a good reason why we
> > can externalize a dictionary but not an array? or in fact, why not just
> > prop_object_externalize() ?
> Because I modeled this somewhat after the CFPropertyList / NSDictionary stuff
> in OS X. Specifically, NSDictionary has -writeToFile:atomically:, which takes
> a dictionary and serializes it to an XML plist file, as well as
> +dictionaryWithContentsOfFile: and -initWithContentsOfFile:. NSObject itself
> has no such method.
Ok, is it worth having a *ternalize_to_file functionality in the library?
Although its fairly trivial to implement, having a standard function would
be useful if usage becomes widespread..
> I would be happy to add internalize / externalize routines for prop_array_t
> (NSArray in OS X has similar methods to NSDictionary's serialization support),
> but I don't want to add generic prop_object_externalize() /
> prop_object_internalize() because it's rather important, I think, to
> explicitly state in the code which you're expecting and let the parser return
> an error when it gets the wrong one.
I'm easy since I have no need for the array anymore, but I dont see any
big deal checking the object type - after all, you must to do that most of
the time anyway.
dict = prop_object_internalize(xml);
if (dict == NULL || prop_object_type(dict) != PROP_TYPE_DICTIONARY)
obj = prop_dictionary_get(dict, "count");
if (obj == NULL || prop_object_type(obj) != PROP_TYPE_NUMBER)
> > As to the utility of using XML for config files, it is handy having the
> > internalize/externalize function and I am going to use that, but after
> > having looked at the output, my opinion is that its not very human
> > friendly at all so better suited for private database files rather than
> > configuration files.
> Perhaps I've simply grown so used to it... I now actively DISLIKE the flat
> config files that BSD uses, because of their lack of structure :-)
Although I think a standardised configuration format and parser is a
desireable thing, and I'm happy with the tree structure, I think that the
lack of readability in XML is a major concern.
would seem to be just as parseable, and much more readable though the
contents of keys might need to be limited to an ascii word (no bad thing?)
Another issue I had was that an internal data type might want to be an
external string type - eg, an IP address is a 4 byte array but in a config
file you would rather it show up as "127.0.0.1".