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:
- pointer conversion to string and back
- query time and sleep in sub-second precision
- generic networking (polling)
- local loopbakc sockets for internal communication
- TCP and UDP on IPv4
- non-blocking stdio
- asynchronous DNS
- running background processes
- file system (file listing and traversal, permissions, file size)
Features to be supported in a later release of libporty:
- more file system: safe creation of temp files and dirs
- more time/date related queries
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:
- high performance web servers with a large amount of requests - because of all the compromises for portability and simplicity, the network layer is not the most efficient possible
- GUI application - depending on a GUI toolkit (like gtk) or library (like sdl) already implies a limited amount of platforms, portability will not be a real option
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.