OLPC platform API / ABI
Background motivation
The traditional Linux OS platform has always offered a wide variety of APIs for accomplishing any given task. For example, for UI creation there is XLib, Motif, GTK+, Qt, WxWidgets; for audio there is Xine, GStreamer, Arts, ESD, OSS, Alsa; the story is repeated across all areas of the development tools stack. While there is much to be said for this diversity (competition drives advancement of all parties, to name but one benefit), the OLPC platform has some unique requirements compared to the broader Linux (or Open Source) platform. Limited memory is probably the most critical constraint - with only 128 MB of RAM to play with and no swap, one cannot afford to have 5 different UI toolkits loaded in RAM. The disk footprint is also important, since every MB consumed by the OS platform further restricts the space for application, and user data - with only 512 MB of flash for storage, the goal is for the platform to be contained in < 200 MB. To deal with these two constraints the OLPC platform will have to be restricted to a subset of what is available in the broader Fedora distribution.
There will obviously be periodic updates of the OS platform, not only to deal with security updates, but also to broaden the capabilties of the platform. With a general purpose distribution such as Fedora, co-ordination between the various RPM repository maintainers can ensure that if an API / ABI in the base OS platform is broken, updates to applications can be pushed out at the same time, to minimise discruption for users. With the OLPC project, however, the vast majority of the end user applications are going to be developed & distributed directly by 3rd party vendors across the world, most of whom will not be known to, let alone in contact with, those providing the OS platform. Thus, there will be little-to-no scope for co-ordinating OS & application updates. The implication of this, is that the OS platform must provide a long term stable API / ABI for application developers to target.
The core API stack
- NB* this list is not yet agreed / reviewed, merely an initial working example around which to base discussions. Join the software mailing list to discuss this further
| Component | Provider | Version |
| C library | GLibC | |
| UI toolkit | GTK+ | |
| Audio | GStreamer | |
| Video | GStreamer | |
| Text rendering | Pango | |
| Messaging | DBus |
Module specific plugins
Audio codecs
- OGG Vorbis
- FLAC
Video codecs
- OGG Theora
Image formats
- PNG
- JPEG
- TIFF
Specific exclusions
While the lists above detail the components making up the official API / ABI, the OS platform does still contain a number of other supporting libraries. For example, GTK+ uses XLib for its underlying implementation. So although this neccessitates that XLib is part of the OS platform, it does *not* mean that it is part of the API / ABI supported for use by application developers.
To help developers writing applications for the platform, the SDK will contain a tool which is capable of verifying that an application only links to officially supported APIs.