Tuesday 14 October 2014

Recursive Knockout.js Templates

A quick example of using Knockout.js recursively with templating to  allow a n-level deep tree to be rendered. I have created a small model and recursive template to render a tree, to look a bit like a tree.
http://jsbin.com/zamese/26/

Monday 22 September 2014

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. 

Tuesday 16 September 2014

Initial Thoughts

Time for a few pictures...
Roughly speaking, the concept separates the act of development into two part, the OS developer and the App developer. The OS developer would provide the services and the stage and the App developer much of the functionality.

OS Diagram
The diagram above highlights what a Web OS may look like. The platform would boot on all devices via the web browser then proceed to load apps based on the users preferences from a store. The Web OS would have a stable API, such that App developers could build reliably for it and it would likely incorporate technologies such as jquery to help with browser abstraction. 

From the perspective of a large company all of these developers may work within the same organisation, but be distributed across multiple continents. This approach allows everybody to work independently on features without impacting each other. Apps can be built to communicate with each other via the Kernel, such that if one is not installed, the platform is tolerant and does not fail. It also does away with large build processes as the Web OS does not need to be aware of the Apps at build time. Everything is only available at runtime. 

Home Screen App Full Screen
Visually ( and taking a slightly Windows Phone view ) the Web OS would run something like this. The actual Web OS would be mostly invisible, providing limited UI features such as basic navigation ( think opening an App and closing an App ). The App would open full screen and would provide its own navigation inside, such as back, forward etc.

Whilst mulling this over some interesting enhancements to the original concept are Web Workers, where the App runs in a thread and therefore has no access to the Web OS memory or the DOM. This provides massive security benefits and performance benefits ( in that sloppy App programming would not hang whole thing and the Web OS can do some basic managing of Apps ). This does create a headache for creating a nice API for the App developer, so that working with the DOM is not cumbersome.

Monday 15 September 2014

OS as a Design Pattern

For a while now, I have been thinking and tinkering with the concept of using operating system principals in a browser framework. The purpose and motivation behind this are: -

  • Scalability for the software: Many we applications are built as a single solution with lots of developer changing code before a build process pulls it all together. This makes large scale deployment hard and large scale development even harder, as it is very easy to trip over each other. 
  • Reduction in boiler plate code: Web Apps require a certain amount of boiler plate code to enable them work, which is then repeated over and over again. Frameworks can help but these tend to be more focused on the UI.  
  • Improved integration: Web Apps deployed within an organisation struggle to communicate with each other and end up relying on adhoc solutions that are susceptible to breaking. 
  • Security: Web Apps hosted in a portal style can easily scrape information from each other, especially if the developer has used global namespace to store information. 
  • 3rd party integration: It is very difficult / impossible for a developer to create a small "app" for integration into a larger product. 

The vision would be something similar to FaceBook / the now defunct iGoogle, which allow 3rd parties to develop secure Apps to be hosted in a larger suite. Obviously the afore mentioned products are large, complex and unavailable for businesses to buy, but would it be possible to develop a similar solution, to allow business to run a platform that can then be customised for/by each individual via an web app market?

Over the next few months I plan to investigate this concept, in design and code, to make a working example and provide the source code open source. I welcome any thoughts and feedback you may have.