Voyager API Design

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

Please see also the page The Voyager API Basics, containing the basic ideas and design goals for 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 excetipon of the section Virtual Base Classes)
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

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, Pipes, more...
Add more...

Basic Device Input/Output

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

This section implements access restrictions and other security methods.

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

System Component Configuration

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
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

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...

Access to streamed data

This section implements access to streamed data, no matter from where the data comes from. For formatted reading/writing of the data, another level of implementation is intended on top of this (see Virtual Base Classes)

Files
Folders (here ?)
TCP/IP, (Named) Pipes
Add more...

Application Potocols

This section implements encapsulation of

SSH
Filesystems (Samba, NFS, more...)
Internet Protocols (http, rtsp, more...)
Add more...

lowlevel GUI

This section implements basic GUI stuff.

primitives
Add more...

highglevel GUI

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

frame window
controls, frame controls
text windows
Add more...

Desktop Objects

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

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

Virtual Base Classes

This is not a real major API part, but a placeholder for all parts of the API, where we could create virtual base classes to allow easy and future safe extension of the Voyager API. The topics listed here could be included in some of the major sections, the reason to summarize it here is to make clear that we need to have a method to create such classes as little frameworks in a consistent way. Here is a first list:

application protocols (including filesystem access)(see section Application protocols)
file or stream format encoder/decoder
System Configuration Components
much more for virtually anything, for all main sections!
Add more...