ISS at FISL 10

June 8th, 2009

The 10th edition of the FISL (International Free Software Forum) will be held at Porto Alegre, Brazil on June 24-27th. Last year the FISL had nearly 7500 participants, thus it’s one of the biggest Free Software events in the world. It’s a great honor to know that this event debuted about 10 years ago as a joint effort between local organizations, companies and universities (including our beloved UFRGS). This shows the strength of open source and free software in this region.

I’m glad to announce that the Instant Syndicating Standards project was selected from over 600 applicants. We will be presenting on the 25th at 9AM. Other Drupal related projects will also be presented (check the full schedule). By the way, FISL’s site is powered by Drupal and the artwork is beautiful!

The sessionLink

June 3rd, 2009

The Drupal WebOS provides several services to the Ext Webtop. The structure of these services are well described and they can either be static or dynamic in nature. The difference between static and dynamic services is that the dynamic services can be seen more as a stream of information and they can be used to provide users with (almost) real-time updates. If there is a great number of dynamic services being requested at a given time, however, the performance of the application can suffer substantially. To solve this issue, we present the sessionLink.

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:

http://webos.iss.im/services/json

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:

http://webos.iss.im/services/json

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.

Foz do Iguaçu

May 11th, 2009

Photos from Foz do Iguaçu:

The serviceLink

March 31st, 2009

The Ext Webtop and the Drupal WebOS are two independent systems loosely coupled that follow a service-oriented architecture. The Webtop requests and receives services from the WebOS. The serviceLink is a structured format that links services together. All services served by the WebOS are well described, allowing the Webtop to do some intelligent data binding. When a serviceLink is invoked, the Webtop verifies what are the required and optional parameters and matches that with the data provided.

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.

Drupal WebOS Overview

March 27th, 2009

While the Ext Webtop acts as the front-end handling user interaction, the Drupal WebOS acts as the back-end providing all the data and services. The key idea behind the Drupal WebOS is the serviceLink, a structured format that creates a link between services. Users can hop from one service to another, including services served by other networks. Services can be combined to create rich mash-ups. The figure below is a screenshot of a service being provided by the Drupal WebOS.

The Drupal WebOS serving the Ext Webtop

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.

Ext Webtop Overview

March 25th, 2009

The Ext Webtop offers a familiar desktop environment that allows users to access services and applications over the Web. The interconnected nature of the Web has inspired the creation of a  distributed desktop, where users can easily share data and services with their contacts. The figure below is a screenshot taken from this environment.

The Drupal WebOS serving the Ext Webtop

The Drupal WebOS serving the Ext Webtop.

The Ext Webtop provides the following features:

  • Multitasking: Open multiple tasks. View tasks simultaneously, aligned vertically or horizontally;
  • Dynamic frames: Observe dynamic frames (list, form, media and social) expand and hide automatically depending on the service. View each frame in full-screen;
  • List: Browse linked data and services from multiple networks. Fetch live data as you scroll. Search as you type. Show extra fields inline. Rank and filter. Select multiple items;
  • Form: View, create, edit and validate forms;
  • Media: View images, videos, or graphs. Navigate conventional websites or self-contained Web applications securely through iframes;
  • Social: Chat and share the task window with contacts. Work collaboratively, navigate websites or watch videos together;
  • Sessions: Save sessions for later. Share a session of the whole desktop environment with contacts in (almost) real-time.

Ext Webtop and Drupal WebOS

March 23rd, 2009

The Web is evolving rapidly and Web applications are starting to reach the same level of functionality of desktop applications. Perhaps we can even risk to say that Web applications will soon surpass desktop applications in functionality given the interconnected and ubiquitous nature of the Web. Despite the differences among Web browsers, there has been an increasing convergence of standards and practices, mostly promoted by the W3C (World Wide Web Consortium) and the Ecma International. The emergence of powerful JavaScript frameworks has also tremendously helped developers to abstract beyond these differences and create rich internet applications easier and faster. Soon, users will be able to access Web applications much like they access desktop applications by using a Webtop, i.e. a desktop that runs on top of the Web browser.

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 ad WebOS.

Web Architecture - towards the Webtop and WebOS.

Knight Foundation sponsors ISS

March 4th, 2009

At this year’s DrupalCon it was announced the winners of the Knight Drupal Initiative, a partnership between the Knight Foundation and the Drupal Community to provide funding for grant proposals that explore digital publishing to transform their respective communities.

I’m glad to announce that our proposal has been approved! Our proposal aims to develop ISS support in Drupal. This will allow people to create and share a personalized stream of information within their social network, helping them to filter and recommend articles to others interested in the same issues.

I would like to thank Jose Zamora and Ken Rickard for all their effort in this process!

Rio Claro – SP

February 21st, 2009

Photos from our new home in Rio Claro, SP:

ISS UI Design

August 13th, 2008

Contacts

The ‘Contacts’ sidebar helps Nick discover new channels created by his personal social network.

The ‘List’ presents all aggregated entries from channels subscribed by Nick. Colors play an important role. Entries in blue are incoming entries, i.e. entries that have been received. Entries in red are outgoing entries, i.e. entries that have been sent. And entries in purple are entries that have been shared.

If Nick wants to share a specific entry, he may do so by tagging the entry appropriately. The Figure shows that this particular entry is already tagged with Science. He may add new tags by selecting them from his own tag cloud, or he may create new ones by typing them. When he syndicates this entry, he publishes this entry to the channels identified by these tags. Everyone subscribed to these channels will receive a notification.

Channels

Nick has associated Debbie’s Environment tag with his Science tag (i.e. he has created a taglink between the two channels). Every time Debbie publishes something tagged with Environment, these entries are automatically tagged with Science for Nick.

Thus, for users to share information, they don’t have necessarily to share the same concepts. All they have to do is to show how their friends’ concepts are associated with their own concepts.

It is important to remember that entries received are not published in Nick’s channels automatically unless they have been approved and shared by Nick himself.