WIAK is a simple, limited, but very efficient, special-purpose, usually non-interactive, extremely lightweight IPC shell written in C.

WIAK stands for, the "WIAK Interface für Application Kontrolle". As an Inter-Process Communications utility, its name reflects its ability to create and control diverse WIAKapps whose component parts may be written in a variety of programming languages and with an assortment of GUI toolkits.

Like most any program, WIAK could be started up as the first main system application, after "init", on boot. However, WIAK is more particularly of the family "shell" in that it can be used to start up (and in some cases control) other processes (or indeed other shells), whilst providing one or more IPC facilities for communicating between the running processes.

Compatible pipe-using commandline utilities and applications can be chained together, and called up and controlled, via WIAK and a WIAK compatible backend server, to produce a WIAK Application or "WIAKapp".

In effect, WIAK is thus a simple IPC subsystem which can be used to dynamically build a complex application by selection from a pool of individually functional parts. The resulting WIAK-created-application, or WIAKapp for short, is itself dynamic and temporary in shape and form, since WIAK does not actually glue WIAKapp component parts together. Instead, it creates through its message passing mechanism an illusion of virtual glue for what are otherwise unconnected processes.

The WIAK project encourages a server/client approach to programming, where, for example, the GUI component of the WIAKapp can act as a client, sending simple commands and other data, via WIAK, to a server application which itself might be a wrapper to a s

Why use WIAK?

For one thing, wiak provides IPC facilities (such as System V message queues functionality) to languages that don't have easy, flexible or any access to them (such as bash script). It also works well with the likes of gtkdialog to create event driven GUI or commandline user interfaces.

It is intended that wiak will eventually provide UNIX and INET socket capability as an addition and alternative to its default named-pipe (fifo) communication channel(s) and the System V message queues. Using wiak as an interface in a new application thus automatically provides the backend (or frontend) application with a convenient communications upgrade path. Furthermore, since wiak is written directly in C, it facilitates system and process control in ways that are often difficult to achieve in some other languages (such as bash). Wiak thus acts as a simple but efficient, versatile and consistent communications interface for commandline-driven applications written in bash or in any other programming language.

Though wiak itself is written in C, there is no requirement that the other parts of a wiakapp need be.

The use of wiak thus liberates the programmer in many ways, simplifies the programming task, and helps to future-proof the application's code.

Finally, wiak is also extremely efficient in its use of system resources:

Each time wiak itself is called, it efficiently performs its task (usually a "--send command" operation) and immediately thereafter closes down (releasing any resources it was momentarily using).

The WIAK Programming Philosophy

A major philosophy of the "wiak programming method", in general, is to keep the User Interface (UI) part of the wiakapp code separate from the main processing. This methodology greatly simplifies the overall coding effort and allows the programmer to readily use different programming languages and GUI widget sets (or non-graphical dialogs) for the user interface.

One of the many advantages of the WAIKapp programming model is that it facilitates the creation of different clients for the same backend server(s), or indeed, different backend server(s) for the same GUI-client. Different versions of any wiakapp can thus be created relatively easily for different systems; the GUI-client, for example, being a separate component, can be simply re-implemented using alternative coding languages and GUI toolkits, and take different design forms, to match the needs of the user or the particular OS distribution.

What's New in This Release:

· The SystemV message queue identification logic and the FIFO naming logic have been modified in order to more logically generate unique identifiers.· The --up option code previously used for forking backend server processes has been removed since an alternative internal mechanism had rendered it redundant.· A bug has been fixed in that alternative mechanism that had prevented the forked process from receiving an argument list.· The provided demonstration applications have been modified to work with these changes, and the documentation has been overhauled as a consequence.