There is widespread enthusiasm for widgets. While a widget is usually based on (a variant of) HTML+CSS+ECMA-Script, in the process of defining communicating widgets, we found it natural to design widgets and widget user agents in SVG+ECMA-Script. Our current interests include widgets for interactive TV, for user interface of UPnP devices, and for the mobile environment. Our work is based on the W3C Widgets specification, SVG Tiny 1.2, and our extensions for widget user agents and for communications. In this paper, we describe our extensions and the use of SVG for widgets suited for a mixed iTV, home-network and mobile environment.
Table of Contents
The W3C also published in december 2008 the version 1.2 Tiny of the Scalable Vector Graphics language (SVG). SVG Tiny 1.2 being able to describe text, vector graphics, audio, video, animations and interactivity, including using XMLHttpRequest, can be used for creating rich widgets. In this paper, we present how we use SVG within our widget work. This usage is twofolds. First, we use an SVG document as the start file of the widget. A single widget may be displayed on different devices and therefore requires to easily adapt to different screen configurations. Indeed, in this paper, we consider widget mobility, that is the ability to move a widget accross devices. For that reason, SVG and its scalability features are of particular interest. Even though, real adaptation of the widget layout to the device screen configuration requires more than scalability, the use of SVG enables simple adaptation and ensures that the graphics used inside the widget will be displayed with an adequate quality on the different devices. Second, we use SVG documents with some ECMA-Script extensions to implement Widget User Agents.
This section discusses our usage of SVG for widgets and widget user agents.
The W3C is currently producing a family of specifications related to widgets. Among them, we have experimented with the "Packaging and Configuration"  and the "APIs and Events" specifications . In ,the SVG language can be used to represent either the icon or the start file of the widget. This is indicated by the use of links pointing to SVG files inside the XML configuration file of the widget package. There is almost no difference between using an SVG document as a standalone document, outside a widget, and using it inside a widget, except when it is used as an icon. In that case some restrictions apply, for security reasons, and scripts are not executed.
The W3C family of specifications does not standardize the complete behavior of the Widget User Agent (WUA). In particular, how widgets are discovered or proposed to the user, how they can be activated, deactivated, moved ... is not standard. In this work, we have developed two WUAs using the SVG language and ECMA-Script together with some additional APIs. One WUA is used for managing widgets on a mobile phone (see Figure 2) and the other is used on TV sets (see Figure 1).
In both cases, the WUA is implemented by an SVG document which deals with the management of widgets. This SVG document implements the following features.
In our implementation, the discovery is performed internally by the player. Currently, only the UPnP protocol is supported but other protocols could be. From an SVG document point of view, an ECMA-Script interface is defined, independent from the discovery protocol, to enable the SVG document to:
determine at any time how many widgets can be presented to the user;
to be notified dynamically of the availability or non-availability of a widget;
and to query the metadata stored in the configuration file of the widget package (name, width, height, link to the icon or to the start file, ...).
The presentation of the available widgets is of course done differently in the WUAs that we have developed depending on screen configurations. For example, the mobile version displays the widget icons on the entire screen, while the TV version shows a list of widgets below the TV program. The SVG document implementing the SVG user agent runs a script which maintains the presentation of the icons, using the <animation> element.
Again because of screen configurations, our WUA allows the presentation of multiple widgets at the same time on the TV, while we have chosen to allow one active widget at a time on the phone. In our implementation, each widget is integrated in the SVG document, representing the WUA, using the <animation> element.
This is an obvious and useful feature of WUA designed for computers, but it is not a feature present in one of our SVG WUAs. It is not difficult to implement, but it is not required when a small screen or only a remote control are used to interact with the WUA.
According the W3C specifications, there are two ways to handle widget preferences. First, static preferences which should be loaded when the widget starts and which are defined in the configuration file using the <preference> element. Second, dynamic modifications of preferences use the 'preference' attribute of the 'widget' ECMAScript interface. Our WUAs currently only supports the <preference> element.
Since we consider widget mobility, in our SVG WUAs, the list of possible target WUAs is built dynamically in the form of SVG elements and presented to the user when he/she wants to transfer the widget. The SVG WUA handles the user interface creation and relies on an ECMAScript interface for the enumeration of target WUAs and for the actual widget migration. The discovery of possible target WUAs uses UPnP, and assumes all WUAs announce themselves as a specific UPnP service.
Existing proprietary WUAs, such as Yahoo! Widgets, propose an advanced presentation of widgets. When a widget is active, its iconic representation in the Yahoo! Dock is live. It is a different representation of the widget than the one presented in the main widget panel but both are synchronized. In our SVG WUAs, we also implemented this possibility. To do that, we design the SVG document representing the widget with the 2 possible presentations: one for the main presentation and one for iconic representation. Then, in the widget configuration document, we indicate the same file for both the start file and the icon file, but with a different fragment identifier. The icon file is a different view of the same SVG file. This works fine for purely declarative widgets. However, for scripted widgets, it violates the limitation of  but it appeared to us as the only option to synchronize the two rendering, without using a centralized synchronization system like a file or a server.
As explained in the introduction, in this work, we have identified the need for a mechanism enabling communications between widgets and communication entities not known at authoring time. These entities could be either remote servers on the Internet, in the home network or other widgets in the same or in a different WUA. In this section, an overview of our solution is presented. The details of the solution are presented in  and . Here, we focus on the usage of this solution with the SVG language.
To enable communications between widget and other entities, we define an abstract communication model. In this model, entities communicate through messages. Messages have zero or more arguments. Sets of related messages are called interfaces.
Each interface is identified by a type and is composed of a set of messages. Each message has a direction (in/out) and is made of several parameters. An incoming message can be notified to the associated widget and the value of the parameters forwarded to the scene. An output message is send when triggered by the scene, its parameters taken from values in the scene.
For all these connections between the scene and the communication description, we primarily use a declarative language. Instants when messages should be sent are described by scene events, e.g. animation starts or mutation events. Similarly, notifications of incoming messages are given using scene events. Values to be used in outgoing messages, or in the other direction to be modified by incoming messages, are described using scene attributes.
For scripted widgets we also introduce the possibility to call script functions upon incoming messages, like a regular event handler; and the possibility to send messages from script using the specific 'invoke' function defined on a dedicated ECMAScript Interface. This interface also offers the 'invokeReply' function to send a reply to an incoming message.
We include the description of the interfaces in the configuration document of the widget package and the WUA interprets it to determine the communication capabilities of a widget. Interfaces start as unbound. WUA are tasked with finding entities with matching interfaces (other widgets, UPnP services, web services, applications...) and binding them as described next.
The WUA is responsible for discovering local and remote services. Services may become available or unavailable at any time. The widget UA is in charge of binding the interfaces of discovered services with the interfaces of the activated widgets. This binding may happen at any time.
First, the widget UA checks the type of the widget interface and compares it with the string identifying the external service type in the service description (e.g. the URN of the UPnP service). If the types match, the widget UA compares the definition of the interface with the description of the service at the message level: for each message in the widget interface, there needs to be a message in the service description with the same name, or the binding fails. Extra messages in the service interface do not cause the binding to fail, this allows to bind a recent widget with old versions of the service. If a bound service becomes unavailable, the interface is considered unbound and the WUA notifies the widget.
Finally, we also consider widgets as source of information for other widgets. In this case, a widget can declare an interface to be a "serviceProvider" and the WUA applies the above method to binding widget interfaces together.
Once we have widget communications, modularity becomes attractive: splitting larger widgets into coherent components. Hence, in our work, we have introduced the notion of widget components. A component is another widget that a primary widget needs to run fully and that it communicates with. A component can be either defined by a reference to the needed widget, e.g. URL to a packaged widget, or by a reference to the interfaces that this needed widget has to implement. This reference is indicated in the configuration document of the widget package.
<content src="distvotemain.svg"> <cw:interfaces> <cw:interface type="urn:telecomparistech:service:communicationtest:1"> <cw:messageOut name="switch"> <cw:output name="newTargetValue" scriptParamType="string"/> </cw:messageOut> </cw:interface> </cw:interfaces> </content>
The <content> element from the W3C Widgets contains one <interfaces> element in our extension namespace using prefix "cw". There is one interface of type urn:telecomparistech:service:communicationtest:1 with one output message. This example assumes the use of scripting. This example defines one single output message, allowing the widget to send commands to a service or another widget. Note: This is part of the interface of the right widget in Figures 3 and 4.
<content src="comwidin.svg"> <cw:interfaces> <cw:interface type="urn:telecomparistech:service:communicationtest:1" serviceProvider="true"> <cw:messageIn name="switch" outputTrigger="status.boolean"> <cw:input name="newTargetValue" setAttribute="set_status.bool"/> <cw:output name="status" attributeModified="status.boolean"/> </cw:messageIn> </cw:interface> </cw:interfaces> </content>
In this second example, the interface has a single input message. The use of the serviceProvider attribute declares that the widget UA should expose this interface as a discoverable service to other devices. The messageIn element has one attribute. The outputTrigger attribute is a string which specifies an entity of the scene description. This entity can be an attribute of an element, specified as "nodeID.attributeName", which is the case here: when the attribute is modified, the message is activated in output, i.e. in this case the reply is sent. Or this entity can specify an event, as "nodeID.eventName": when this event is fired, the reply is sent. Or this entity can be a script function name: when this function is called, the reply is sent.
The input element has a setAttribute attribute of type string, specifying an attribute of an element, specified as "nodeID.attributeName". The received message contains a value for argument "newTargetValue": this value is passed onto the scene description entity, i.e. the attribute is set to that value.
When the widget is ready to reply and the outputTrigger has happened, the value found in the scene description entity specified by the attributeModified attribute (an attribute of an element, specified as "nodeID.attributeName") is sent out.
Note: The above is part of the interface of the left widget in Figures 3 and 4.
<content src="head.svg"> <cw:simplifiedContent src="edit.svg"/> <cw:interfaces> <cw:interface type="urn:telecomparistech:service:fileSelector:1" bindAction="onBind_setDir"> <cw:messageOut name="setDirectoryName">...</cw:messageOut> <cw:messageIn name="selectedFile" inputAction="fileSelected">...</cw:messageIn> </cw:interface> </cw:interfaces> <cw:component src="../list/config.xml" activateTrigger="mygroup.click" deactivateTrigger="myg2.bool"/> </content>
In this third example, the widget has one interface with two messages (details ommitted), and one reference to a component widget. The activateTrigger attribute specifies that when the element mygroup of the calling widget receives a click, the component widget is activated. The component widget is found by a direct reference to its package in the src attribute. When the attribute myg2.bool of the calling widget is modified, the component widget is deactivated. Finally, the attribute bindAction of the interface specifies the script function to be called when the component widget has been activated and the binding of the interfaces has happened.
Our system is implemented in GPAC, an open source multimedia framework for research and academic purposes in different aspects of multimedia, with a focus on presentation technologies (graphics, animation and interactivity), developed at Télécom ParisTech . We have created three widget UAs with wildly different goals:
Our first SVG WUA is dedicated to interactive TV. Its user interface is very limited. It is possible, but not very useful to run multiple widgets concurrently. Position and size of the widgets cannot be changed by the user. It has a "Yahoo! Connected TV" style. 
Our second SVG WUA emulates the iPhone UI. Only one widget can be visible at a time, in full screen, alternating with other running widgets and multiple pages of widget icons, à la iPhone home screen. By experience, this is our preferred UA for testing remote widget communication.
Our other WUA is very generic and complex. It allows any number of concurrent widgets, and includes a user interface to load and unload widgets. It has a dock à la Mac OSX. The position, size and state of any widget can be modified by the user, in a Apple Dashboard or Netvibes kind of way.
The WUAs are implemented in a mixture of C++, ECMA-Script and SVG, as an extension to the GPAC browser. Widgets can be implemented in SVG, BIFS or any other media type supported by GPAC, such as Flash, VRML, X3D, LASeR and DIMS, regardless of the widget UA implementation language.
Note: the scripting context of the widget UAs is different from the scripting context of the widgets, which is very restricted and isolated from the widget UA scripting context by a layer of C++. This ensures maximum security from potentially hostile widgets.
Note : we have also implemented other WUA using the BIFS language following the same principles...
[Demo of iPhone-style widget UA]
[Demo of various communicating widgets]
[Demo of widget components]
Figure 4. the same widgets after clicking on the power switch. The switch command was sent (right to left) and then the status information was sent back (left to right)
Here are some of the advantages of our design and implementations:
The system will work with any protocol for discoverable services and devices: our implementation uses UPnP, but we will be extending this in the future.
The actual location of the services is transparent: our widgets are independent from the device they run on; service location independence is provided by the WUAs thanks to the interface type abstraction.
One widget may be connected to multiple services, or one service to multiple widgets, or widgets to widgets.
It is possible to move widgets between devices: we have implemented two mechanisms in this area. The first is a mechanism by which a device serves to other devices the widget which will allow the other devices to drive the serving device. The second is a mechanism by which the user can choose to "move" a widget which already runs on device A to another device B.
It is possible to split widgets into communicating pieces: we have implemented examples of such widgets.
It is possible to have asynchronous connection and disconnection: we have implemented widgets which get connected (resp. disconnected) as soon as the service they are using appears (resp. disappears) on the network.
The system works on very small devices, without a scripting engine: useful scriptless widgets can be designed.
In , Sire et al describe an inter-widget communication system. The system is HTML-based and uses scripting APIs for communication. One significant difference with our system is their choice to implement the "widget UA" with a combination of a normal web browser and some PHP code server-side. They define drag-and-drop, which we have not. However, they are confined to communication with widgets in the same browser, whereas our communication is with other entities, widgets and services including those running on other devices. There is also a security issue: a hostile widget has access to widget container information, and from this, to other widgets information.
In this paper, we have presented our work on the usage of SVG for communicating widgets. This work is based on the use of SVG widgets, of an SVG-based Widget User Agent with ECMAScript extensions and on a declarative mechanism for communications between scripted and/or script-less widgets. Our work is to be used in both an interactive TV context and a home-network context. We believe that the combination of W3C widgets, SVG and our communication extension to be uniquely well suited for a global solution integrating widgets from Internet, from the mobile environment, from interactive TV and home network, allowing crossovers.
This work has been partially financed by the European Network of Excellence INTERMEDIA (IST-FP6-38419).
[] Marcos Caceres. W3C. Widgets 1.0: Packaging and Configuration. available at http://www.w3.org/TR/widgets/ .
[] Marcos Caceres. W3C. Widgets 1.0: APIs and Events. available at http://www.w3.org/TR/widgets-apis/ .
[] Copyright © 2009. ACM. Declarative Interfaces for Dynamic Widgets Communications. September 15 - 18, 2009. Symposium on Document Engineering. 9. Munich, Germany. .
[] Copyright © 2009. ACM. Widget Mobility. September 2 - 4, 2009. International Conference on Mobile Technology, Applications and Systems. Nice, France. .
[] Copyright © 2007. ACM. GPAC: open source multimedia framework. DOI=http://doi.acm.org/10.1145/1291233.1291452 . 1009-1012. September 25 - 29, 2007. International Conference on Multimedia. 15. Augsburg, Germany. .
[] Yahoo!. Yahoo! Connected TV information. available at http://connectedtv.yahoo.com/ .