Subject: Re: XML config file
To: Iain Hibbert <plunky@rya-online.net>
From: Jachym Holecek <freza@dspfpga.com>
List: tech-userlevel
Date: 07/23/2006 16:15:29
# Iain Hibbert 2006-07-22:
> 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.
You can externalize as usual and send the resulting string "per partes"
yourself. It's the internalize part that would need to be modified (ie.
internalize a consistent dictionary snapshot received in multiple chunks).
> > > 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 },
> };
The strings here would be dictionary keys, right? The above would cover
most practical needs, I guess.
-- Jachym