Voyager API Basics

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

Please see also the pages

• The Voyager API Design containing the design/coverage of the upcoming Voyager API
• The Voyager API Design and Implementation Guide - containing the methods and rules for implementing the Voyager API

Voyager Main Page

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 e.g. Triton (to be implemented)

• Supported APIs (to be ported/implemented)
  • APIs of supported/integrated libraries
    • GLIB, GTK+, Cairo, TCP/IP, more...
  • Integration APIs for scripting engines
    • REXX, Ruby, Python, Perl, more...
  • Compatibility APIs (to be ported/implemented)
    • 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

Please refer to the Voyager API Design and Implementation Guide.