This message is partly summary of my understanding of the state of the
discussion, partly an attempt to describe my own world model, and
partly an attempt to convince people to do some things my way.
1. DATA MODEL
We seem to be agreed that the data stored will be a set of name->value
pairs. We broadly agree that the names are in a hierarchical
namespace, and that the values are byte strings not containing nulls
(usually, text strings).
We have yet to agree on the correct representations for `variable
keys' (eg mail-transfer-agent/<domain>/..., and lists
(mail-transfer-agent/allow-relay-hosts).
The variable keys have the same possibilities as values. Clearly we
can handle lists using variable keys, provided there's a suitable
`list keys' operation.
We can handle variable keys as a new kind of data value (a `hash' or
something, a la perl), or by having a variable namespace. Personally
I prefer the latter as it's more flexible. The former means we have
to invent new value syntax, whereas new namespace syntax is easier
given that we get to define the namespace syntax anyway. Variable
keys having the variability encoded in the namespace rather than the
value fits better with our typeless data model, and prevents errors
where arrays are found where values are expected, or whatever.
Also, if we invent a new kind of structure, it's much easier to do if
we encode it in the namespace.
So, in summary, I propose that we invent (or name) an encoding of
arbitrary octet strings and nominate it as the standard encoding for
situations like
mail-transfer-agent/<domain>/...
and that we make sure that we have a `list sublevels at this level'
operation.
In order not to introduce type into the structure (to avoid
incompatibility), data must be storable at branching nodes as well as
leaves, but this should be avoided in actual designs.
2. DATA FLOW
We seem not yet to agree about whether there is one database on the
host, which data can be loaded into and retreived from, or a set of
databases which are merged at lookup time.
I'm still in favour of a single database, and doing merging by running
`merge this into the database' commands, for the reasons I've set out
before.
3. FLOW-OF-CONTROL
My suggestion about a special exit status etc. has been misunderstood
slightly, probably because I didn't completely specify it.
I was suggesting that the main mode of navigation of this data at
least initially would be via a wizard-like interface which would
be called from postinst scripts instead of the current ad-hoc
prompting (or possibly at some earlier point).
I think that in this case it makes sense for the user interface which
is acquiring some data to offer the user a `back' option if possible.
The presence of this option should be controlled by a parameter to the
query interface function, which would be called from programs or
scripts which needed information.
The returned value from the query would be a value, a failure
indication, or a `back request' or possibly later other kinds of
navigation request.
The suggestion about the exit status was basically a quick and easy
way to make current imperative postinsts which gather data and then
act work and have a functional `back' button.
4. STRUCTURE, AND NATURE OF APIs
I have the following view:
| | |
| v v
| +-----------------------+ +------------------+
| | general reconfig tool | | dpkg/dselect/apt |
| | published to admins | +------------------+
| | (implement later) | |
| +-----------------------+ |
| | | | |
| | | `-----------. |
| | | | |
| | | .........|.....|.............
| | | | | maintainer
| | | | | script API,
| | | | | perhaps
| | | | | extended a bit
| | | v v
| | | +-------------------------------+
| | | | package configuration code |
...|................ | | | eg query script or postinst |
| merge and dump | | +-------------------------------+
| interface | | |
| published to | ..|.....................|...........
| admins | | Query/fetch API | fork/exec
| | | published to |
| | | package maintainers |
| | | |
| | v v
| | +-------------------------------+
| | | core |
| | | (validates data as requested, |
| | | decides whether to prompt) |
| | +-------------------------------+
| | | |
| ............|....|....... ...........|.........
| DB API | | C or ? fork/exec | UI API
| internal | | | published to
| | |calls | UI developers
| v v v
| +----------+ +-------------------+
`---------------->| db code | | UI implementation |
+----------+ +-------------------+
||
,----.
|----|
| |
`----'
Should the interfaces be C or program call or something else ?
I think that at least the user interface query API should be a program
call interface, because it is much easier to dynamically replace
functionality called via program invocation than that called via a C
API (even a shared library). Doing things this way will make it easy
to add new `user interface styles' like `none' or `GTK'.
The combined fetch/query API is the one used by maintainer scripts.
Obviously it eventually needs to be available in both C and program
call forms, but I think the first requirement is for a program call
interface.
Ian.
