[devel] kast design

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

Hello list!

I see that kalyxo mailing lists are quite dead lately :/. The primary 
discussion is taking place on irc and noone is doing reports or anything. So 
i thought i would try to drag the lists back to life a bit.

So, there is a first subject of recent discussions, the design of KaST, our 
system tool. We plan to build on foundation of debconf, retaining as much of 
backward compatibility as possible.

I started to write down the current design proposal in the wiki 
(http://www.kalyxo.org/twiki/bin/view/Main/KaST). If you don't understand 
some part of the proposal, please speak up. It is still rough and may assume 
deeper knowledge of debconf. I'll try to improve it gradually so it is well 
understandable and consistent.

- -- The proposal: ----------------------------------------------------------
- ---+ KaST - the Kalyxo System Tools

Kalyxo system tools are based on DebConf system. They are analogous to Progeny 
Configlets, but kast provides a python library to access debconf database in 
more natural and easier way, for one. The source for kastlib is in KdeCvs, in 
kdenonbeta/kdedebian/kast. Design document is being prepared and should be 
available shortly.

- ---++ Requirements and Expectations

What we want to achieve:
   * Easy to use, nice, custom interface (ie, not a registry editor).
   * Try to restrict (config) data flow from actual conffiles to frontend as 
little as possible. This won't be always possible. KaST should have 
mechanisms in place to deal with incomplete data sets and fuzzy change 
applying (preferably with configurable level of user checking).
   * Try to make writing configuration units (a backend + frontend pair) as 
easy as possible. If we manage to write the UI abstraction layer (see below), 
both could be part of maintainer scripts of a package.

- ---++ Design

- ---+++ Overview
The current design is following:
   * The value cache: DebConfDB
   * The frontend
      * DebConf, the wizard-ui manager
      * KastConf, the configlet-ui manager
      * KastConfLib, a library common for all KastConf implementations
   * The backend: semi-bidirectional bridge between actual config data and 
value cache

- ---+++ The DebConfDB Interface
The DebConf interface has separate library, used by both backend and frontend. 
It is supposed to make handling debconf values as transparent and natural for 
given programming language as possible. There is a proof-of-concept library 
written in python. It will be, however, rewritten in perl, but with semantics 
as similar as possible.

- ---+++ The Backend Library
The backend library should provide several generic mechanisms for 
configuration data manipulation and retrieval. In ideal case, it would 
provide means to nearly fulfill the criteria set forth in previous section, 
without having to write fine-tuned backend with full parser and generator for 
every single config file (satisfying the config unit simplicity criteria).

The techniques considered for inclusion in backend library:
   * Partial context match and value rewrite; values are retrieved from config 
file using a regexp match on value context; they are replaced with whatever 
frontend supplies using a regexp substitution using the context plus the old 
value
   * Guarded section in configfile (with robust checking for changes, like 
md5sum): suitable for file formats where user can override things by simply 
repeating the statement/assignment/whatever with different value; can be 
combined with above for parsing

Also, for user feedback, backend should supply a diff of changes it is about 
to apply to frontend and let the user validate it (if sufficient level of 
control was assumed by the user).

There should be a way for admin to mark files as unmutable for kast, though 
kast itself should detect condition where it was unable to parse (possibly 
heavily modified) file and indicate it to the user, asking to override manual 
changes completely from fresh conffile template (backing up the modified file 
for restoration and comparison purposes).

- ---+++ The Frontend

The frontend is split into three parts. The kastconf UI, the debconf wizard 
and the driving logic. In an ideal case, both the wizard and UI are 
completely dumb, ui having only the UI description and the wizard just order 
of questions to ask. The logic should use the kast frontend library to drive 
both of those. The library will speak a simple protocol, along the lines of 
debconf itself, to drive the UI manager (either debconf or kastconf). To ease 
writing of this logic, we will design a simple declarative language to 
describe the questions to be asked. This declarative language will be most 
probably compiled into a perl script that will become the driving logic. The 
perl code will be different for the KastConf and DebConf, but it shall be 
created from common set of declarations and the right branch will be invoked 
automatically.

- ---++++ KastConf
KastConf is a system, similar to debconf, in that respect it is used to ask 
user things and fills in debconf database. In addition, it has a feedback 
system, to allow for value-change notification and interactive operation. It 
does not use wizards, but frontend-specific UI description. This will be .ui 
file with some restrictions for KDE frontend. Other frontends may use other 
means, or maybe common spec may be created (not very likely tho). Every 
KastConf frontend will be a separate implementation of KastConf, using a 
single shared protocol implementation (which will be written in perl). The 
frontend (KastConf implementation) will be responsible for storing the 
ui-descriptions.
- ---------------------------------------------------------------------------

- -- 
Peter Rockai (mornfall), mornfall()logisys!dyndns!org, mornfall.homeip.net
- ---------------------------------------------------------------------------
He says gods like to see an atheist around. Gives them something to aim at.
                       -- (Terry Pratchett, Small Gods)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBA9o7vQmfopLcAqkRAvpKAJ46OA673RfwKPAI+Chb/XaHWDbODgCdEQNv
vuIjiKj46JOUnI9dpt220dM=
=P5GH
-----END PGP SIGNATURE-----