Instant Operating System
IOS (Instant Operating System) is an open standard that allows systems and users from different networks to communicate with each other over the Web.
Users today access services solely from the corresponding website, having to navigate to another website when they want to access other services. Additionaly, mashups of services are not a common practice. This is due mainly to the restrictions imposed by the same origin security policy implemented by browsers. By using CORS (Cross-Origin Resource Sharing), IOS allows users to securely access services from different networks from a common user interface.
The key concept behind IOS is the serviceLink, which is a structured format that links services together. Users can jump from one service to another, including services served by other networks. For example: a user may browse his way to a friend's profile and become aware of her interests by visualizing her tagCloud. If there is a common interest, the user may subscribe to a channel and create a tagLink that connects her remote channel with his local channel. All this can be done from a unique user interface. The fact that the friend is from another network is totally transparent to the user.
In the server-side, we have seen the consolidation of the LAMP stack and its derivatives, which consists of an Operating System, a Web Server, a Scripting Language and a Database. On top of this stack, we have seen the emergence of Web
frameworks for managing content, users, apps and services. It's important to notice that traditionally the management of these has been the responsibility of Operating Systems. However, to take advantage from the key aspects of the Web, this responsibility is being delegated to “the cloud” and up the stack. In other words: content, users, apps, and services that before were managed by the
local Operating System are increasingly being managed by a remote server, at the Web framework level. This trend will ultimately lead to the emergence of a WebOS, i.e. an Operating System that runs on top of the Web server.
Following this trend, IOS proposes a service-oriented architecture where we have a WebOS on the server-side, providing the data and services, and a Webtop on the client-side, providing a rich user interface. The openness and interoperability provided by this architecture will allow users to access multiple WebOS from a single Webtop, as
demonstrated by the figure below:
IOS also defines the following set of core services:
- Services: Expose web services. Provide access across different networks securely
- Users: Register users. Assign Roles. Give permissions. Manage personal contacts lists
- Content: Create content with associated fields. Handle form display and validation
- Channels: Create channels and link them together (tagLink). Aggregate and syndicate entries
- Files: Store documents and files. Handle image, audio and video. Export file types
- Language: Provide localization. Translate strings and content to different languages
- Search: Provide federated search results for both structured and unstructured data
- Sessions: Save and record sessions. Assist in providing instant sessions among users.
By separating the logic (represented by the WebOS) from the user interface (represented by the Webtop), users are able to easily share their WebOS with each other, providing data and services. The figure below illustrates this
The communication between two users might be intermediated by both WebOS or just one of them. A service such as chat, that requires a low latency, will use only one WebOS. This keeps the communication fast and responsive. The use of two
WebOS is appropriate for services that keep records at each side. For example, when a user syndicates an entry, this entry gets forwarded to all subscribers, even if they are offline. The WebOS of the subscribers are responsible for receiving and saving these entries for later retrieval.
The Webtop and the WebOS are two independent systems loosely coupled and governed by a very limited set of rules. Even though the IOS standard defines a set of core services, what really drives the communication between the Webtop and
the WebOS is the serviceLink, a structured format that links services together. In the Use Case Editon of this book, we'll provide a brief example of this communication. A more complete example with technical details is available in the Developer's Edition.
In our example, a user logs into his WebOS. He decides to access his contacts list, so his Webtop makes a call to the User service. His WebOS sends back a serviceLink with a list of all his contacts, including their names, pictures, and their corresponding WebOS.
The user selects a friend. A call to the corresponding WebOS is triggered. Her WebOS provides a serviceLink with a list of the main services available, such as her profile, a list of her latest entries, a list of her channels, etc.
The user visualizes her tagCloud and discovers a common interest (a channel identified by a tag). Selecting this channel triggers a call to her WebOS that provides a serviceLink with a list of entries from this channel.
The user decides to subscribe to this channel and associate it with a channel of his own. This subscription made from his Webtop triggers a call to his WebOS that creates a tagLink linking her remote channel with his local channel. His WebOS makes a separate call to her WebOS informing the channels that have been taglinked.
At a later moment, the friend posts an entry on this channel. Her WebOS immediately sends this entry to all subscribers, including the WebOS of the user. The user happens to be online, and receives a notification of this new entry.
He likes the entry and decides to syndicate it. His WebOS also sends this entry to all subscribers. This entry gets propagated to friends and friends of friends as long as it remains relevant. All WebOS involved work together to disseminate this information in a peer-to-peer fashion.
The Web is losing its open and distributed nature and becoming increasingly closed and centralized. Today, a handful of companies exercise a great deal of control over the Web. Each one of them is progressively strenghtening their lock-in strategies, making it more difficult for users to migrate to other providers or to interact with each other from different systems.
For example: Facebook users can only interact with their friends on Facebook itself. So even if they were able to export a list of friends, this would be pretty useless. Plus, with network effects in play, by leaving Facebook, users lose the ability to view entries published by their friends since this is where it has become the default place to share things over the Web.
This closed and monolithic nature inhibts innovation. Users only have the option to use the systems developed by the service providers themselves and have no way of customizing them. Unfortunatelly, this centralized architecture is used by just about every website, forum, and social network today, either as a lock-in strategy, or because of the technical challenges of creating a more interoperable system using existing Web technologies.
IOS hopes to challenge this by promoting an open architecture that provides extensibility and interoperability over the Web. Our use case demonstrated how to implement ISS/IM using IOS, but other services could be developed as well. We hope that in a near future, users will be able to be served by multiple WebOS in a transparent and secure manner.