This page describes (official) Applications that ships with WOSH.
A WOSH Application is defined as a generic software based on WOSH Framework.
Such applications are designed for end-users (inhabitants) and system/home administrators.
Main goal of WOSH applications is to load, setup and boot the WOSH Kernel. Usually they also expose some access/viewport to the user (graphical or console). Because of that, these application are not expected to be complex and grow as the framework and its services.
Beginners and Windows' users should give a look to WOSH WorkShop: a graphical application designed (mostly) for the administration of the whole system. WoshShop is a good example of standalone vs. distributed/remote management, it can control transparently the local kernel (integrated) and any reachable remote kernel both.
Another graphical application, started recently, is WOSH KiosK. KiosK is designed specifically for the inhabitant user, preferably running on a touch-screen device. KiosK is the most user-friendly WOSH application.
WOSH CE Server is a minimal server designed for on smartphones and embedded devices, it hosts a specific bundle which exports messaging and communication services to the WOSH Network (assuming device is always connected to the network).
Last but not least, WOSH Server is a console (CLI) application running WoshKernel and a standard I/O console to WOSH Shell. It is designed to be (one of) the main server and run 24/7.
Expert users and developers just love shell and ssh, WOSH Shell is a mimimal (console) client application designed to control WOSH System (remotely).
Binaries are always built in /bin directory (eventually sub-folders).
Once a stable release of WOSH is available, applications will statically or dynamically link against the WOSH Framework library and bundles will be loaded from shared or dynamic libraries.
Consider a WOSH server (such as woshsrv), it makes sense to have the WOSH Kernel on it because it hosts services (bundles).
Generally speaking, frameworks and middleware are useful because of abstraction, rapid development and well-defined interfaces/features. So, why a graphical application like a remote controller or an embedded system should implement custom accessing layers? In fact, having them based on the same micro-kernel will speed up and simplify development and maintenance both.
In other words: a WOSH application ships with a WOSH Kernel and acts as one host of the WOSH network. The 'main' WOSH server running on the Residential gateway (home server) and the WOSH Remote software (running on the laptop) are two idempotent hosts of the WOSH network by many (most) points of view.
All WOSH applications are clients and servers at same time.
As said in previous sections, WOSH Applications share the underlying layer (micro-kernel) and the (optional) configuration profile, because of that the application flow follows the same structure.