Voyager API Design

Welcome to the Wiki Page explaining the design of the Voyager API.

Please see also the pages

• The Voyager API Basics - containing the basic ideas for the Voyager API
• The Voyager API Design and Implementation Guide - containing the methods and rules for implementing the Voyager API

Please note

• The page is organized as a list of sections, where each section names a specific major part of the Voyager API (with the exception of the section Virtual Base Classes)
• The title of the major part includes the proposed prefix for class/method/Symbol names (here: class name prefix, all uppercase)
• Each section API may be used as a base for an API of another section, where applicable
• Take into account that the API will likely be implemented as an object oriented class library. Using the Netlabs Object Model this will be compiler and language independent (so e.g. C and Classic REXX can also be used)
• If you have additions or a completely new main section, please feel free to add it
• If you feel that a part of the structure better would be reorganized (joining or splitting major sections, moving parts between major sections), please contact the netlabs.org core team first for prior discussion. However, all suggestions and comments are very welcome and highly appreciated!

Voyager Main Page

System Resources & Management - SYS

This section implements system near resource handling (including kernel related hardware)

• Wrapper for Kernel Services, Memory, Interrupts, Timer, ACPI
• DMI (incl. Process Management)
• Interprocess Communications
  • Shared Memory, Semaphores, Queues, (Named) Pipes, more...
• Add more...

Basic Device Input/Output - DEV

This section implements input and output from and to peripheral hardware for applications, and encapsulates existing APIs (where possible, in a unified manner)

• Keyboard, Mouse
• Sound
• Video
• USB
• Firewire
• NICs, other adpaters
• more...

System Security - SYS or SEC

This section implements access restrictions and other security methods.

• refer to Security/2 design ?
• Add more...

System Component Configuration - SYS or CFG

This section implements configuration of system components (possibly also application components via a framework ?)

Here is a list of goals:

• encapsulates any kernel specific means of configuration
  • like driver config (per config.sys, registry, ini file ...)
• implements an internal (?) database for configuration data (like OS2.INI or Registry)
• may superseed DMI, and a DMI implementation may use this part of the API
• includes Disk & Partition Management
• Add more...

System Service Management - SVC

This section implements the means for managing system or application services

• see the design sketch from Warpstock Europe 2005 as a proposal: ALL04 - Service Management for OS/2 and eComStation (requires StarOffice 5.1 or OpenOffice.org)
• Add more...

Unified Data Access - ???

This section implements a unified view on data (fuse alike)

• Filesystem Protocols incl. Named Pipes (Samba, NFS, more...)
• Internet Protocols (http, rtsp, SSH, more...)
• Add more...

lowlevel graphics - GPI

This section implements basic GUI stuff.

• primitives (lines, circles, more...)
• font rendering
• image handling (scaling, blending, more...)
• Add more...

highlevel GUI - GUI

This section implements highlevel GUI features used for creating windows, controls and so forth.

• frame window
• controls, frame controls
• text window (support for terminal window)
• Add more...

Preliminary list of GUI classes to be implemented.

Desktop Objects - WP

This section implements nothing less than all classes that implement the workplace Shell replacement.

• (a.k.a. Workplace Shell Replacement and its objects)

Preliminary list of desktop classes to be implemented.

(Virtual) Base Classes & Frameworks

This is not a real major API part, but a placeholder for all parts of the API, where we could either

• create (virtual) base classes to allow easy and future safe extension of the Voyager API or
• create a general framework for a given purpose

Depending on the issue, a given framework or (set of) base classe(s) possibly could be put into one of the above main sections as well, or end up in a completely new section. This may happen during the discussion.

Here is a first list:

• Netlabs Object Model (NOM), runtime for the Voyager specific API (see the Design goals for the Voyager API)
• support classes (strings, arrays). Preliminary list of classes to be implemented.
• application protocols (including filesystem access)(see section Application protocols)
• Resource Management
  see design proposal from netlabs.org Developers Workshop 2007: Managing Sets of Program Resources
• file or stream format encoder/decoder
• System Configuration Components
• access to streamed data (file stream, TCP/IP stream, more)
• internet protocols
• much more for virtually anything, for all main sections!
• Add more...