libporty - design decisions, scope and goals

Scope and goals

Scope of libporty is providing a minimal set of API for a group of system services which have different interface from system to system. When selecting which system services should be included, the rule of thumb is that libporty should support I/O related calls, and not anything that can be easily (re)implemented by the user application.

For example networking is supported, because networking API is different on each variant of UNIX and can not be implemented without support from libc or system calls. In contrast, string operations like strncasecmp() which is not present on many system is not something libporty would try to support, as it is easy to provide a portable implementation that does not depend on libc or system calls. The only exception are the functions of the util package. These are all required by the high level packages of libporty, and once they are already needed to be implemented in libporty, there is no reason not to provide API to them. However, the strict rule is that this package will always have only the functions that are really required by other parts of libporty, and never general "should be useful for the application" ones.

Where there are multiple alternative methods for solving a problem, for example IPC, libporty will pick one and will support only that.

Platforms

Target platforms are commercial UNIX systems from the late 80s and on, free systems based on UNIX (Linux, Minix, BSDs, OSx), Windows based on the NT kernel and generally anything that is close enough to UNIX/BSD roots or POSIX.

A few examples of platforms which are not targeted: plan9, VMS, DOS, CP/M.

Features

Currently the following topics are covered (to some degree) by libporty: Features to be supported in a later release of libporty:

Applications

Scope in terms of application is small and medium scale CLI utilities and daemons which do not require to squeeze maximum performance out of the system but should be portable. Examples: TODO.

A few examples which libporty is not optimized for:

design decisions

communication

Sometimes there are multiple backround tasks controlled by libporty or the application, for example async background processes or async dns queries. To avoid parallelism, libporty offers only one communication method: non-blokcing, pollable local sockets (also refer to the next section). Although it is not as CPU-efficient as shared memory, queues or signals, the only supported IPC is also local sockets.

async main loop

Althought libporty does not implement any main loop, and supports blocking socket operation as well, the API suggests the application would work in a single thread with an async main loop organized around the P_poll() call.

common minimum

Libporty is aiming to support the common minimum of its target platforms. This means some features are not implemented because they could not be implemented on all target platforms. For example passing file descriptors or using IPv6. This guarantees that an application properly developed with libporty will really run on all supported platforms.