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)
		errx(...);

	obj = prop_dictionary_get(dict, "count");
	if (obj == NULL || prop_object_type(obj) != PROP_TYPE_NUMBER)
		errx(...);

> > 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.

Simplistically,

item1 {
	key1	"string";
	key2	0x33;
	key3	[
		0x33;
		"string";
		true;
		true;
		<junk>;
	];
	key4	false;
	key5	<datablock>;
	key6	{
		key6.1		"string";
		key6.2		0xabcd;
	};
};

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".

iain