Re: dpkg-db

[Brederlow <goswin.brederlow@student.uni-tuebingen.de>]

Wichert Akkerman <wichert@cs.leidenuniv.nl> writes:

> I've been doing a bit of coding on a database for the configuration
> management. The thing doesn't have a name yet, but then again it
> doesn't do anything currently either.. I've just revamped all major
> datastructres which broke everything.

The Database should be able to translate freetext variables.
Since this probably doesn't mean anything to you, heres what i mean:

Lets get back to the old Gateway example :)

Package Netconfig {
   Variable Gateway {
	name="HaveGateway"
	type="bool"
	value="no"
	default="no"
	question="Do you have a Gateway?"
	help="A Gateway is a ...."
   }
}

question and help would be free text and schould be translated to the
current language.
Each dep file should contain a catalog for each language it suports
that give translations. The catalog would contain the original text
and its translation followed by some seperator.
The Database should keep track of those catalogs and when asked for
some variable, which contains free text, it should give the translated 
text instead of the original.

> Anyway, I've though a bit about the shell interface to the database. 
> What I'm going to do is make a simple utility called dpkg-db which
> allows you to access the database. Here is its documentation as I
> envision it:
> 
> ------------------------------------------------------------------------------
> Shell interface: dpkg-db
> 
> The commands:
> 	create <variable> <template> <package>
> 		Create a new variable using <template>
> 	remove <variable>
> 		Remove variable <variable>
> 	check
> 		Check database integrety
> 	query <subcommand> <variable>
> 		Retrieve information about a variable
> 		Subcommands:
> 			value        - get value
> 			type         - show variable type
> 			default      - show default value
> 			description  - show short description
> 			ldescription - show long description
> 			defined      - check if variable has value
> 			meta <flag>  - check if metaflag <flag> is set
> 	(un)set <subcommand> <variable>
> 		Set or unset information for a variable
> 		Subcommands:
> 			value        - change the value. with unset we remove the value
> 			               from the database.
> 			meta <flag>  - (un)set metaflag <flag>
> ---------------------------------------------------------------------------

How should containers be returned to the shell script? Vectors would
probably be the best, butit could be tricky with containers containing 
containers. Another aproach would be to use a syntax like C uses for
structures, except with a _ instead of a .,
e.g. Netconfig_gateway_hasGateway for package Netconfig, container
gateway and variable hasGateway.

> Feel free to make suggestions, since I haven't written a single line of
> dpkg-db yet.
> 
> Please note we have three seperate entities:
> * templates: a description of variables, can define new variable types using
>   containers.

Can you give some examples please, I'm not sure how that should look
like.

> * variables: a list of (template,name) pairs that define the variables
> * the database: place were we store the actual value for variables, if they
>   are defined. (ie the instantiations of the variables)
> 
> On a somewhat related note: I have a friend who is going to do research
> on processing huge amounts of data. For that he needs a database which
> can handle multiple database drivers, and it seems he could use the same
> codebase. I made the whole metavariable-stuff optional in the library,
> so we should be able to make it quite fast (he needs to process
> something like 100 megabyte/sec). I thought this would make a nice
> testbed for high-duty situations :)

Sounds good. Although because of the special access (many variables
from the same section) special speed optimisations could be made for
Debian, which would even be faster, if needed by speedomaniacs. :) 

> Wichert.

May the Source be with you.
			Goswin