Contents

Sycoca - Introduction

Sycoca stands for System Configuration Cache and is nominated to be the successor of kregistry. It is a
light weight database optimized for looking up static system configuration information fast and with
minimal memory usage.

The database will offer read-only access to many clients at once. The database is
read-only which means that looking up can be very fast since no locking or transaction operations need to
be performed. The database is created/updated by kbuildsycoca from human readable configuration files.
kded monitors these configuration files and will call kbuildsycoca to update the
database when a change in any of the configuration files is detected.

Updating the database will mean that the database is replaced as a whole by a more up to date version.
This approach allows a very straight forward database implementation. With Sycoca it will not be necessary
any more to parse multiple files when looking for static system information. Instead Sycoca can return the
requested information with a performance near to O(1). Examples of static system information are mimetype
bindings and .desktop information (servicetypes). Application specific configuration information will _NOT_
be stored in Sycoca since this information is usually subject to regular change.

Using Sycoca in your application

Applications never use sycoca directly but always through classes provided by the KDE framework.
The following classes use sycoca to obtain their information:

Class that provides information about a protocol supported by KDE. These protocols can be used in a URL and will map to an IO-slave that supports the protocol. Examples of protocols supported by KDE are "http", "ftp" and "pop3". The KProtocolInfo class provides information about the capabilities of a protocol. An example of a capability is whether the protocol can provide a list of entries similar to the contents of a directory.

Class that provides a (possibly nested) listing of services. Used for things like a hierarchy of applications (K-menu), hierarchy of settings (Control Center) or list of screensavers (screensaver setup in control center)

Class that provides information about a service (or more specific about "applications"). A service is always described by a .desktop file. Such a file contains information like which icon to use for the service, how to start the service, the (translated) name of the service and (translated) comment which describes the service. See the Desktop Entry Standard for a description of .desktop files.

Mostly known due to one of its subclasses KMimeType. KServiceType describes a certain type of service that can be offered by a service. In the case of KMimeType the type of service is the ability to open a file of a specific format. A typical sequence of events, implemented by KRun, is to determine the mimetype of a file and then to search for a service that supports this mimetype. E.g. a file is examined and identified as a HTML file (mimetype text/html) based on this information, one or more services can be found that are able to open this file (for example konqueror, netscape and kwrite)

Maintains a specific number of information types in the Sycoca database.

Identifies which human readable configuration files to use for creating which kind of KSycocaEntry's.

Builds fast lookup indices inside the database for the KSycocaEntry's managed by it.

Stores the KSycocaEntry's it maintains in the database.

Looks up information in the Sycoca database and recreates KSycocaEntry's to represent this information.

KSycocaDict

KSycocaDict offers a fast lookup-index based on string keys. Creation of
the index is reasonably slow, but once the index has been created information
can be found with a small number of steps nearly independent from the data size.

During creation KSycocaDict creates a hash-function and a hash-index which
is populated for approximately 20% and which has a typical hash collision
chance of 10%.

This means that existing objects can be found at once in 90%
of the time. In the other 10% the collision list has to be searched.
A collision list typically contains 2 entries.

Not existing objects have a chance of 20% to give a false hit. A hit should
therefore always be verified by loading the actual object.

KSycocaDict is used by the KSycocaFactories to be able to create fast lookup
functions for the objects it maintains.

To speed up the dereferencing of relations between KSycocaEntries of various kinds, the id of the KSycocaEntry should be used to store these references.

When e.g. KMimeType creates itself based on the database and its Id it should check that the information labeled with this Id in the database, does indeed belong to a KMimeType type of object. (Watch out with multiple inheritance!)