Instant Desktop Environment

Instant Operating System

Instant Syndicating Standards

Alpha CrucISS Webtop

PolarISS WebOS

StarCloud

Now imagine a generic content type called iContent that could be transformed into anything instantly by the average user. This content type would include all available types of fields (text, number, date, file, etc) with an unlimited cardinality (i.e. the fields could be repeated if necessary).

So let us suppose a user wants to enter a Recipe. He selects the iContent and starts building the structure on the fly. He adds the Title, then the Ingredients, later the Instructions, and finally a Photo. Now, he might want to enter a Movie. So he adds a Title, then the Director, later the Duration, then the Release Date, the Genre, a Picture, and finally the Plot. He might want to save both the Recipe and Movie structures for later use as templates. But notice that only one content type was necessary to build such different content structures.

This is a simple idea, but a very powerful one. It makes us rethink how we create information today. Email, for example. You only have the option to enter the Title and the Body. No other fields are allowed, with the exception of Attachments, which provide the flexibility we are looking for since it has an unlimited cardinality. Why not extend that same flexibility to the other fields? Blogs are another example. Imagine how much richer would the Web be (semantically) if blogs had this kind of flexibility?

Let’s see an example to illustrated the point: Nick and Debbie are friends and they have subscribed to each other’s feed to receive updates. Their feeds are hosted on different servers.

In the Pull model, Nick has to poll Debbie’s server every time to check for updates from Debbie, and vice-versa.

In the Push model, the flow goes something like this:

1. Debbie publishes a new entry on her server (Push);
2. Debbie’s server lets Nick’s server know that Debbie has published a new entry (Push);
3. Nick polls his own server to receive updates (Pull).

Notice that the second step is a Push implemented in HTTP. Nick’s server didn’t have to poll Debbie’s server every time to check for updates.

In essence, this is what RSSCloud and PubSubHubBub are trying to accomplish: promoting an architectural design that follows the Push model using HTTP. ISS implementation on top of Drupal is also promoting this.

Yes, the third step is still the Pull model, but so what? Polling is only performed when the user is online and active, and strategies like the sessionLink can help determine how frequently the client has to poll.

Regarding the ISS implementation on top of Drupal, when a user syndicates an entry to a channel, all friends that are subscribed to this channel are notified (even if they are from a different server). The notification to a different server is done via the Services module.

Since ISS encourages a more decentralized social network and the ISS policies limits who gets notified, this helps in terms of performance and scalability. The speed at which information propagates will only be limited by the speed of the social network to filter information, which guarantees a high quality and very personalized stream of information for each individual.

Our presentation entitled ISS (Instant Syndicating Standards) was great! We gave a quick overview of ISS and many attendees got interested in our work. One of the highlights of the presentation was when we used tennis balls to explain how the information would travel in the social network. It was really fun to see the balls been thrown from one side of the room to the other. Some photos of the presentation are shown below:

Bruna Griebeler at FISL 10

Tiago Rosa da Silva at FISL 10

Daniel Schmidt da Silva at FISL 10

In the 90s, after Tim Berners-Lee created the World Wide Web at CERN research center, scientists around the world were able to share information with their colleagues by setting up their own personal Websites. The key concept behind the Web was the hyperlink, which allowed users to browse Web pages across different networks.

With the popularization of the Web, browsing Web pages just wasn’t enough. So by the turn of the millennium, the advent of search engines came to people’s assistance, most notably from a search engine created by Larry Page and Sergey Brin while at Stanford University. Powered by complex algorithms, search engines would rank and present Web pages to users based on keywords.

With further popularization of the Web, searching again wasn’t enough. The top-down presentation of Web pages selected from a huge collection by an algorithm has created a very undemocratic way of sharing information. In this next decade, users will rely less on monolithic algorithms and more on their own personal social network for sharing information.

While the first decade of the Web was all about browsing and the second decade was about searching, the next decade will be about syndicating. Users will connect with their personal social network to receive and disseminate information in a bottom-up manner. Information, services and interactions will all be syndicated, allowing users to share not only information but also rich and profound experiences.

Sharing Information

As of today, there is no existing technology that allows individuals to share information in a bottom-up manner on a global scale. ISS (Instant Syndicating Standards) is a proposal to create just that: a distributed worldwide recommender system perfectly tuned to output a very personalized stream of information for each individual, where information flows from the personal social network towards the whole wide world. This is accomplished by allowing each individual to create their own broadcasting channels and to connect these channels with the ones created by their personal social network. This trustful and cascading network of syndicated streams filters out irrelevant information, while still letting good information pass through at each level.

The key concept behind ISS is the tagLink. The tagLink is a semantic link created by individuals showing how their friends’ channels are connected with their own channels. If a user becomes interested in a particular channel from a friend, he may subscribe to this channel and add it to his own channel. Thus, each individual receives exactly what he wants based on these subscriptions, and all information that reaches them goes through friends’ approval first.

Sharing Services

ISS is being developed as a set of services on top of Drupal. This service-oriented architecture promotes interoperability and allows individuals from different networks to share information with each other. The ISS services englobes user, channel and content management. These services together with services that provide file, language, search and session management will transform Drupal from a Content Management System into a Web Operating System.

The key concept behind the Drupal WebOS is the serviceLink, which is a structured format that links services together, including services from different networks. For example: a user may browse his way to a friend’s profile and become aware of her interests by visualizing her channels. 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. The fact that the friend is from another network is totally transparent to the user. This is possible when these systems follow a set of open standards called IOS (Instant Operating System). Users will be served by multiple WebOS.

Sharing Interactions

The services provided by the Drupal WebOS can be accessed through a Webtop, i.e. a Desktop Environment that works on top of the Web. The Ext Webtop is a Webtop created using the Ext JavaScript Library following a set of open standards called ITOP (Instant Desktop Environment). From this Webtop, users can share interactions with each other.

The key concept behind the Ext Webtop is the sessionLink. The sessionLink is a service that follows the publish/subscribe pattern and provides users and applications with (almost) real-time updates for subscribed services. For example, when a chat application is loaded in the Ext Webtop, the Webtop subscribes to the user.im service to be kept aware of any updates. More sophisticated interactions may also be shared, including sharing the whole Desktop Environment (this is called an Instant Session). In an Instant Session, when a user opens a window in the Webtop, his friend sees the window being opened. Likewise, when his friend closes a window, the user sees the window being closed.

Conclusion

In this text, we have presented ISS (Instant Syndicating Standards), an open set of standards that challenges the top-down model of information-sharing and gives place to a bottom-up model, where each person has a unique voice and equal opportunity to contribute and benefit. In this way, we hope to bring people closer together to discuss common interests and share information in a more open and democratic manner.

Also, we have presented the IOS and ITOP open standards, which we believe will help people to have more rich and profound experiences. We want to bring the Instant from Instant Messaging to the Web. And by Instant, the most important aspect that we want to exploit is not so much the When, but the Who. We want to empower individuals to “exchange” their Operating Systems and Desktop Environments with friends much the same way that they exchange Messages with friends when using Instant Messaging applications.

Along these two decades, the Web has evolved tremendously. The Web’s influence in democratizing access to information is evident. Yet, there is still a long way to go before reaching a truly democratic Web, where information flows freely in all directions. Also, there is still a long way to go before reaching a truly interactive Web, where people can connect with each other to create rich and profound experiences. We hope that the work here presented will help shape the way we share information, services and interactions in the next decade, as we believe that this will fundamentally shape us into better individuals and into a better society as a whole.

Acknowledgements

I would like to thank the following organizations for sponsoring my work:

• The GIMSCOP research group from UFRGS university for sponsoring the development of the Drupal WebOS and Ext Webtop. Special regards to my mentor Dr. Jorge Otávio Trierweiler.
• The PPGC (Computer Graduate Program) from UFRGS university and the CAPES brazilian federal agency, who provided me with a scholarship to develop ISS. Special regards to my mentor Dr. José Valdeni de Lima.
• The Knight Foundation, for sponsoring the development of ISS on top of Drupal. Special regards to the UFRGSWeb team for helping me out and for giving me the opportunity to mentor them.

I would also like to thank the following open source communities for their contributions:

• Dries Buytaert and the Drupal community. Special regards to Scott Nelson for the Services Module and Dmitri Gaskin for the JSON Server Module.
• Jack Slocum and the ExtJS Community. Special regards to Todd Murdock for the Web Desktop extension and Thorsten Suckow-Homberg for the LiveGrid extension.

Further Information

• ISS (Instant Syndicating Standards)
• IOS (Instant Operating System)
• ITOP (Instant Desktop Environment)

References

• http://iss.im/references

The sessionLink is a service that follows the publish/subscribe pattern and provides users and applications with updates for subscribed services. For example, when a chat application is loaded in the Ext Webtop, the Webtop subscribes to the user.im service to be kept aware of any updates.

The following is a simplified description of the user.im service:

{"method": "user.im",
"sessionlink": "payload",
"time": "2000",
"sid": "14"
}


The “sessionlink” can either be set to none, payload or timestamp. Services by default are static and there is no need to define sessionlink. A dynamic service on the other hand must have “sessionlink” set to payload or timestamp. When payload is set, the session.link service will return the payload for the subscribed method. Otherwise, if timestamp is set, it will only return a (unix) timestamp, thus requiring the Webtop to make an additional call to receive the update. For applications like chat, where speed is essential and the content is small, it’s recommended to set sessionlink to payload.

The time can also be set. This will help determine how often the Webtop will have to poll the session.link service. The lowest time of the current set of subscribed services is used. For example, if the Webtop is calling session.link every 30 seconds and the user loads the chat application, then the Webtop will start polling session.link every 2 seconds (2000 milliseconds).

The subscriptions are managed automatically by the Webtop by calling the session.subscribe service:

method=session.subscribe
sid=14


The user.im service has a sid (Service ID) of 14. The session.subscribe service actually handles sid as a string, thus enabling the Webtop to subscribe to several services at the same time (just use a comma to separate the sids).

To unsubscribe, there is the session.unsubscribe service that works the same way. If the user closes the chat application and he or she is not talking to anyone else, the Webtop can unsubscribe from the user.im service:

method=session.unsubscribe
sid=14


In conclusion, the sessionLink is a key component that helps the Webtop to be kept aware of any updates in an easy and straight-forward way. This component will help developers create applications that provide real-time collaboration and offer users a more seamless experience.

The following is a simplified description of the user.list service:

{"method": "user.list",
"args": [{"name": "uid", type: "int", "desc": "User ID", "required": "0"}],
"return": [
{"name": "name", type: "string", "desc": "Name of the User"},
{"name": "sl", type: "int", "desc": "ServiceLink"},
{"name": "uid", type: "int", "desc": "User ID"}],
"type": "list"}


And a simplified description of the user.load service is presented below:

{"method": "user.load",
"args": [{"name": "uid", type: "int", "desc": "User ID", "required": "1"}],
"return": [
{"name": "uid", type: "int", "desc": "User ID"},
{"name": "name", type: "string", "desc": "Name of the User"},
{"name": "mail", type: "string", "desc": "Email of the User"},
{"name": "picture", type: "string", "desc": "Picture of the User"}],
"type": "form"}


This might be the JSON result returned when requesting user.list:

{"list":{"items":
[{"name":"Ariel Kempf", "sl":"1", "uid":"2"},
{"name":"Jorge Trierweiler", "sl":"1", "uid":"4"},
{"name":"Marcelo Farenzena", "sl":"1", "uid":"7"},
{"name":"Ricardo Duraiski", "sl":"1", "uid":"3"}],
"total_count":"4","version":"1"},
"servicelink":{
"fields":["sl"],
"actions":[
{"Select All":"javascript:selectall()"},
{"Unselect":"javascript:unselect()"},
{"Add New":"local:user.add"},
{"Delete":"local:user.delete"}],
"prefix":[{"local":"http:\/\/localhost\/drupal\/services\/json?method="}],
"alias":[{"1":"local:user.load"}]
}}


The list provided can have special fields representing a serviceLink. This is specified in the serviceLink’s “fields”. In this case, we have only one field: “sl”. It’s also possible to call multiple services simultaneously. All we have to do is add new fields and list them in the serviceLink’s “fields”. This way, we can display a new list, a form, a media, fetch some data, all at the same time.

A serviceLink can be a remote service from any network, or a javascript function. The “actions” provides data that populates the menu in the list’s toolbar. This let’s users perform actions. For example, the user can select a specific user and delete it (local:user.delete). Or the user may select all users (javascript:selectall()) and perform some other action. The “prefix” tells the Webtop that it should substitute “local” for “http://localhost/drupal/services/json?method=”.

By clicking on the first row (Ariel Kempf), the user.load service is called. This service requires uid as a parameter. The Webtop performs some intelligent data binding and passes the uid from this first row (uid=2). The user.load service returns a form. This form is displayed inline, showing more details about this particular user.

One other interesting thing to notice is the use of “alias” as a shortcut. This is important for a long list where for any row we call one unique service (or a few different services). If all services are different, then there is no need to add an alias.

The Drupal WebOS serving the Ext Webtop.

The Drupal WebOS provides the following features:

• 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. 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.

In the server-side, we have seen a 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, applications and services. Notice that traditionally the management of these has been the responsibility of Operating Systems. However, this responsibility is being delegated up the stack so that it can benefit from the key aspects of the Web. This trend will ultimately lead to a WebOS, i.e. an Operating System that runs on top of the Web server.

The figure below illustrates this evolving architecture. The main goal of this publication is to explain how to develop Web services and applications following this architectural design. More specifically, the objective of this publication is to to explain how to develop Web services and applications using the ExtJS framework as a Webtop and the Drupal framework as a WebOS.

Web Architecture - towards the Webtop and WebOS.

• Each individual generates a social graph beforehand consulting the cascading taglinks;
• A query can be sent to friends up to x degrees apart, where x is define by the user;
• This query is published on the users’ searched node with an ID and a TTL;
• Friends may accept the query and see if they have entries that match. If so, they send the IDs of the matched entries and publish that to their matched node. The query is kept alive until the TTL expires or according to the policies;
• Users receive the matched entries in their aggregator. These appear associated with the original query and separated from the main flow of the aggregator.

Further Reading:

• OpenSearch, (2008);
• XEP-0055: Jabber Search, (2008);
• JQbus: social graph query with XMPP/SPARQL, Dan Brickley, (2008);
• Decentralized Meta-Data Strategies: Effective Peer-to-Peer Search, Joseph, Sam; Hoshiai, Takashige , IEICE Transactions on Communications, Volume E86-B, Number 6, p.1740-1753, (2003);
• Looking up data in P2P systems, Balakrishnan, Hari; Kaashoek, M. Frans; Karger, David; Morris, Robert; Stoica, Ion , Commun. ACM, Volume 46, Number 2, New York, NY, USA, p.43–48, (2003);
• Designing Semantic Publish/Subscribe Networks using Super-Peers, Chirita, Paul-Alexandru; Idreos, Stratos; Koubarakis, Manolis; Nejdl, Wolfgang , Semantic Web and Peer-to-Peer, December, (2005);
• EDUTELLA: a P2P networking infrastructure based on RDF, Nejdl, Wolfgang; Wolf, Boris; Qu, Changtao; Decker, Stefan; Sintek, Michael; Naeve, Ambjorn; Nilsson, Mikael; Palmér, Matthias; Risch, Tore , WWW ‘02: Proceedings of the 11th international conference on World Wide Web, New York, NY, USA, p.604–615, (2002);
• The anatomy of a large-scale hypertextual Web search engine, Brin, Sergey; Page, Lawrence , Computer Networks and ISDN Systems, Volume 30, Number 1–7, p.107–117, (1998);
• The PageRank Citation Ranking: Bringing Order to the Web, Page, Lawrence; Brin, Sergey; Motwani, Rajeev; Winograd, Terry , (1998).