On Sat, 22 Jul 2006, Jachym Holecek wrote:

> *ternalize_{to,from}_file(int fd), #ifndef _KERNEL would be useful. One
> other thing that would be nice is the ability to parse/dump dictionaries
> across buffer boundaries. I have two specific use cases in mind:

one problem with this, is that if whomever is passing information from a
dictionary, and passes a part of it, then the information changes, then
the user wants the next part - what to do?  I guess it would have to be
limted to immutable dictionaries, but I'm not sure how far immutable
goes. Is it all the way down?  I dont see anything about mutability for
objects.

> If we can agree the above makes sense, I could probably volunteer some
> time to work on it. But maybe I'm just pushing proplib beyond its intented
> usage.

Once you have a standard way to pass extensible data to and fro, its bound
to be used..

> It would also be sweet if one could check dictionary key names and
> types while the thing is internalized -- at least I prefer to be strict
> when parsing a configuration file, ie. warnx/errx when (syntactically
> correct) garbage is found.

Yes, though I found that validation is not too onerous in reality.

> > { example format }
> >
> > 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?)
>
> I like this. Limiting key names to ASCII is not a problem, IMO.

Though, I seem to recall Jason mentioning that the XML format is just an
initial implementation. It should be possible to just lift out the XML and
drop in another format transparently if so desired.

> > 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".
>
> For userland use, one could prefix strings with a hint on how to interpret
> them. Something like writing 'ip4#"127.0.0.1"' and them register a
> string-to-datablock converter for "ip4" prefix. But this might just be
> overcomplicating the whole thing...

Well, thats what we like to do here :)

I was having kind of the same thought, though I was thinking more along
the lines of combining the parse hints with the validation hints. That
way, there is nothing in the external representation - but the internalize
function gets told how to interpret what it finds.  I'm not sure how this
would best work, maybe provide some kind of (static, const) structure that
describes the layout and what to do with certain fields.

struct prop_hint {
	const char *name;
	prop_type_t type;
	void       *arg;
};

struct prop_hint service_hints[] = {
	{ "smtp",	PROP_TYPE_DICTIONARY,	NULL	},
	{ "nntp",	PROP_TYPE_DICTIONARY,	NULL	},
};

struct prop_hint hints[] = {
	{ "name",	PROP_TYPE_STRING,	NULL	},
        { "address",	PROP_TYPE_STRING,	ip4	},
	{ "services",	PROP_TYPE_DICTIONARY,	service_hints },
};

prop_object_t
ip4(prop_string_t str)
{
	/* we transform the string object to our preferred form */
	return obj or NULL;
}

	dict = prop_dictionary_internalize(xml, hints);

and if anything is not mentioned in the hints, it is just passed through
as normal. Does anything like this exist in the OSXAPI?

iain