Voyager API Basics

Welcome to the Wiki Page explaining the design goals and basic information on the Voyager API.

Foreword
The developers of OS/2 and eComStation have always favoured the API of their platform over other platform APIs, because it is solid and stable, well structured, consistently designed and mostly easy to use and understand. In the attempt to create the new Voyager platform, the developers taking part in it intend to provide an API being of the very same, high quality. While not everything can be implemented from the beginning that can be thought of, we aim at a design that can be extended in an easy and meaningful way and thus is and will be future safe. For that we intend to setup methods for assuring quality in the ongoing design of this API.

This page explains the basic thoughts on the API design and concerning this, reflects the current status of discussion in the netlabs.org core team. Nothing is completely decided yet, but we expect that this will not change (much) anymore.

Please see also the section The Voyager API Design. This has been separated from this page, as we expect it to receive much more frequent changes.

What is the Voyager API
It is essential to distinct between all APIs supported by the Voyager platform, and the Voyager API - or better, the Voyager specific API. If we talk about the Voyager API, the latter, so the bold printed part of the following list is meant.

Currently we see the following distinction:


 * Voyager API (to be implemented)


 * Supported APIs (to be ported/implemented)
 * APIs of supported/integrated libraries
 * GLIB, GTK+, Cairo, Triton, TCP/IP, more...
 * Integration APIs for scripting engines
 * REXX, Ruby, Python, Perl, more...
 * Compatibility APIs
 * eCS & OS/2: VIO,MOU,KBD
 * Posix ?
 * more...?

Reasons for a Voyager API
We see the following reasons to provide a Voyager specific API and not to go for a new platform without a specific API
 * encapsulate Voyager specific and kernel specific implementation details
 * allow program development independently from the supported APIs/libraries
 * provide an easier API compared to the sum of APIs of the supported libraries
 * suitable for most used cases
 * requires only a flatter learning curve - better for beginners

Design goals for the Voyager API
The follwing topics are currently suggested as the design goals for the Voyager API:
 * implement as an object oriented class library
 * use Netlabs Object Model (NOM)
 * allows bindings for non-OO compiler and script languages
 * allows better binary compatibility for external extensions
 * no 1-1 implementation of (one of) the underlying libraries
 * trade in some flexibility for simplicity
 * cover approx. 60-80% of the used cases of the supported libraries
 * gain the same reputation concerning quality like the OS/2 API
 * see this API as advertisement for Voyager as an exemplary development platform