[bind10-dev] Data/command definition language

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So we now have a communication channel, and a way to store arbitrary data. The
next step is a way to define the data models and external interaction on them.
Here are some thoughts that i have about this right now. They are very much a
work in progress, so comments are welcome before i start coding this :)

Place in the bigger picture:

Upon startup, a module connects to the command channel. It sends its data
definition structure to configuration manager, and queries the configuration
manager for a previous set of settings.
(note: the config manager could also read the data definition from a default
location, and only provide it to bigtool when it knows the module is running, or
maybe even always and return MODULE_NOT_RUNNING or something, so you can also
change settings of things that are off).

The bigtool would then on startup query the config manager for all
known modules, and would then know all possible commands (open question; what to
do when a module gets added while the bigtool is still running?)

There are now 3 places where we can do validation; the bigtool can validate
changes and commands while they are made, the config manager can validate
changes before they are stored/propagated, and the modules can validate changes
and commands prior to accessing them, so it will always know the exact contents
of the data.

(and yes, i'm aware that i am kind of reinventing both a subset of xml schemas
and netconf here)

Data definition:

The data definition is expressed here as a data element itself, with fixed names
for certain items. Of course we could also replace fixed names by lists with
fixed locations, but while this method is much more verbose, it is imo also a
lot more self-explanatory and less error-prone.

See definition and example below.

possible additions:

- - allow 'typing'? (allow definition of named data_item_specs and
  referrals to them? see the example, the zone
  element is defined three times right now)
- - extend with optional constraints (like min/max for ints, regexes
  for strings)
- - also define return types for commands? (for instance, currently
  the zone list command returns a list of elements containing zone
  names)

Definition
- ----------

data_spec:

{ "data_specification":
	{
	"module_name": "<name>",
	"config_data": [ <data_item_spec> ],
	"commands": [ <command_spec> ]
	}
}

data_item_spec:
{
  "item_name":		"<name>",
  "item_type":		"<type>",	// int, double, bool, string
					// list, or map (or any?)
  "optional":		<true|false>,
  "default_value":	<Element>	// element type depending on
					// item type
	                                // mandatory if "optional"
					// is false
  "map_spec": 		[ <data_item_spec> ],	// only for maps
  "list_spec":		<data_item_spec>	// only for lists
}

command_spec:
{
  "command_name":	"<name>",
  "command_args": [ <data_item_spec> ]
}



EXAMPLE
- -------

specification:
{
  "data_specification": {
    "module_name": "parkinglot",
    "config_data": [
      {
        "item_name": "port",
        "item_type": "integer",
        "item_optional": false,
        "item_default": 5300
      },
      {
        "item_name": "zones",
        "item_type": "list",
        "item_optional": false,
	"item_default": [],
        "list_item_spec": {
          "item_name": "zone_name",
          "item_type": "string"
          "item_optional": false,
          "item_default": ""
        }
      }
    ],
    "commands": [
      {
        "command_name": "zone_add",
        "command_args": {
          "item_name": "zone_name",
          "item_type": "string",
          "item_optional": false,
          "item_default": ""
        }
      },
      {
        "command_name": "zone_delete",
        "command_args": {
          "item_name": "zone_name",
          "item_type": "string",
          "item_optional": false,
          "item_default": ""
        }
      }
    ]
  }
}

data:
{
  "port": 5300,
  "zones": [
    {
      "zone_name": "tjeb.nl",
    },
    {
      "zone_name": "jinmei.org",
    }
  ]
}

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrwZOEACgkQ4nZCKsdOncUpegCgwEXC7XngahK3EhEZ/fza0uuK
vDIAn3ixHQWcDLmpPnxK6ioHQwDUAjVm
=z/9U
-----END PGP SIGNATURE-----