Scene setting

The purpose of the design pattern is to abstract a common implementation style, for repeated use. Therefore the next step is to boil down the idea to a basic concept that can be implemented.

An Operating System essentially provides a number of services, on top of which applications can be built. The Web OS pattern therefore needs to provide three key features: -

• A common base, which controls the invocation of the Services and Apps, a s well as all communication between them. 
• The ability to register new Services
• The ability to register new Apps. 

The Pattern should not dictate an implementation, style or look, but rather guide the developer on what can be achieved, why and provide a sample concrete implementation.

Taking this into consideration, a starter for ten on what the os pattern should look like, gives us this: -

• Bootloader: Config and startup.
• Common Base: The low level communication and control platform.
• Service A: A basic trusted gui service that will alert messages to the screen.
• App A: A basic untrusted app that sends messages to the screen.

The diagram above shows the basic structure of the pattern. The Services should be trusted by the OS, so that they can interact more closely with the run platform. For example in a web implementation I would expect a service to handle all IO, such as XHR communication or WebSockets, which would be isolated away from the Apps, such that the App developer would call a "send" with some JSON formatted data and the platform would take care of the rest, routing the message to the IO service and on to the backend. 

This level of integration allows a core platform to be solidly tested and upgraded, adhering to a core API, which can then be implemented by App developers in safety. 

Apps should be less trusted that than Services, the Kernel should restrict as much of their capabilities as possible. Once again this would be implementations specific, but in the example web app above the App could be run in an IFrame, to prevent it interfering with the outside DOM.

As the platform grows in complexity, Services and Apps would interoperate more and more to achieve more complex goals. Examples of such services would be Authentication, UI, Security, IO and Storage, with an App being able to request information from all of these and potential pass this on to another App.