summaryrefslogtreecommitdiffstats
path: root/gnome1-libs/bonobo-conf/DETAILS
blob: bc647ea5f65481f49aea9f8985e3ee40bf65e93d (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
           SPELL=bonobo-conf
         VERSION=0.16
	  BRANCH=`echo $VERSION|cut -d . -f 1,2`
          SOURCE=$SPELL-$VERSION.tar.gz
SOURCE_DIRECTORY=$BUILD_DIRECTORY/$SPELL-$VERSION
   SOURCE_URL[0]=$GNOME_URL/sources/$SPELL/$BRANCH/$SOURCE
     SOURCE_HASH=sha512:cb6373cc40e2e9b9d9172b2a50c3b8ff5fa9a939c6aef5807b27f7bc950db808a6b031786b0b78395d9bd9f760dc4920ea8af1e36604cd5fb35e2319d39146a9
      LICENSE[0]=GPL
        WEB_SITE=http://www.gnome.org
         ENTERED=20011109
         UPDATED=20021103
        KEYWORDS="bonobo gnome1 libs"
           SHORT="The Bonobo Configuration System"
cat << EOF
The Bonobo Configuration System (BCS) consists of several parts. An API
to access configuration data, a database to store configuration values
in XML format and a system to visualise and edit configuration data. The
whole system is built on top of bonobo and ORBit (CORBA). There are
several APIs to access the configuration data, and the API can be chosen
through the bonobo moniker system. It is up to the programmer to decide
which interface is best for a given application. The configuration 
system allows you to store the data with various backends. Although BCS
is shipped with it's own XML based backend, it is also possible to use
GConf, or LDAP as backend. The configuration database architecture is a
reimplementation of the GConf architecture developed by Havoc Pennington
using Bonobo-native idioms. Some configuration systems only permit you
to store a limited set of types. We have removed that limitation so that
we can now store CORBA:any which is very convenient in some situations.
EOF