Other Hiker Services

Abstract IPC

The Abstract IPC service provides a lightweight, robust interface to a simple message based IPC mechanism. The actual implementation can be layered on top of other IPC mechanisms. The current implementation is based on Unix sockets, but this mechanism can be layered on other IPC mechanisms if required. The current implementation has a peer-to-peer architecture that minimizes context switches, an important feature on some popular embedded architectures. This mechanism is not meant to define the sole IPC mechanism available on ALP – all the other familiar IPC mechanisms continue to be available; rather, Abstract IPC provides a preferred and unified mechanism used in the implementation of the ALP components.

The Abstract IPC Service comprises an API for a simple interprocess communication (IPC) mechanism used by the framework components described on this site.

The goals of this design include:

Independence from underlying implementation mechanisms (e.g. pipes, sockets, D-BUS, etc.)
A simple, easy to use send/receive message API
Support for marshalling/unmarshalling message data
Minimization of context switches by sending messages directly between processes without passing through an intermediary process

The IPC mechanism is based on a single server process exchanging messages with one or more clients. The server process creates an AlpChannel. Clients connect to the channel and receive an AlpConnection pointer they can use to send/receive messages to the server. The format of the messages is completely up to the server and clients of the channel.

Communication can be synchronous or asynchronous. When done asynchronously, processes receive messages via a callback mechanism that works through the gLib main loop.

Detailed information on Abstract IPC can be found here.

libsqlfs

This library is a layer above the very popular open source SQLite database software. Libsqlfs was created to help Global Settings, but it may be useful in other ALP components too. It provides an easy way for applications to put an entire read/write file system into a relational database as a single file in the host file system. Such a filesystem can easily be moved around, backed up or restored as a single file. But the file system can also be accessed as individual files using open, read, write etc (not SQL). This provides great flexibility and convenience.

Why

The motivation for creating a filesystem-to-database-file bridge originated with PalmSource's need for to store and retrieve application and system preferences (similar to the Registry in Microsoft Windows). Such a service must allows keys to be organized in directories or in a hierarchy like pathnames in a file system.

Other alternatives

Open source software such as GNOME manages system preferences using a component called GConf. We hoped to re-use GConf for the ALP registry. GConf provides directory hierarchies in the key space, but unfortunately it does not have permission-based access to individual settings.

A key specification for mobile devices is the OMA-DM specification, which defines a common set of system settings for cell phones. This specification requires support for secure settings, whose access must be limited to applications with specific credentials. We considered enhancing GConf with permission control, but there were other factors.

GConf currently stores its data in XML files. That provides the convenience of XML processing, which may be overkill when there are small amounts of data (less than a thousand settings, say). GConf also lacks support for batching setting changes into groups of transactions. A real database supports transactions. GConf's design allows the possibility of database backends, but to date we are not aware of such an implementation.

Benefits

We concluded that a simpler way to meet our needs was to write a library that supported the POSIX filesystem semantics on an SQL database. This brings the benefits of a real database, such as transactions and concurrency control, and allows us to have complete control over the schema of the preferences, so we can allow additional metadata such as value types, permissions and access control lists.

Our libsqlfs registry can accommodate small preference values such as a number, and large binary objects such as an video clip. The library provides a generic file system layer that maps a file system onto a SQLite database, and supports a full subset of POSIX filesystem semantics.

To speed development, we built our file system mapping layer as a File System In User Space (FUSE) module. FUSE is another open source project, a kernel module that supports user-level implementations of file systems. Our design allows libsqlfs to implement a real file system at the OS level, and apply real file system operations on it. We tested the complete build process of gcc and the Linux kernel on top of libsqlfs, and we successfully executed fsx.c, the Apple file system test tool, against libsqlfs.

Today, the Hiker Global Settings component uses libsqlfs as the storage backend. libsqlfs provides an easy way for applications to support a read/write file system totally contained in a relational database as a single file in the host file system, without using SQL statements. Libsqlfs provides a superset of the storage features of GConf, and can be used as the storage backend of other desktop preference services. Libsqlfs is also useful wherever developers need to organize data, and sometimes treat it as one file, and at other times treat it as a collection of individually writeable files.

Back to "About Hiker... "