The Unity Webapps Service

3 Unity Webapps Service

The Unity Webapps Service

An introduction to the Unity Webapps Service

The Unity Webapps system is designed with a simple goal: Integrate Web applications in to the Unity platform. A first thought here, might view this as a matter of binding various Desktop APIs in to to the Web application host. However, many metaphors are different in the case of Web Applications, and there are a few issues to solve:

- A WebApp may have multiple application instances, which operate independetly of eachother. This is the client side, view component of the application, such as multiple browser tabs. In this case, how do we avoid multiple instances of an application fighting over API resources (such as Indicator status)?
- Likewise, a traditional Desktop Application is assosciated with a window, or a group of windows. In the web application case, an application may be split between multiple top level windows, each of which contains multiple applications! There may in fact be no native window at all assosciated with a Web application, how then can other applications ask to activate it, tell if it is active, or dispatch various callbacks to it?
- A WebApp can not be trusted to use Desktop APIs at arbitrary rates, or download resources of arbitrary size
- In some sense, a WebApp is always running, and views from it are frequently destroyed and reinstated. For example, on a page reload, GMail should not flicker from the desktop!

It is to solve these goals, that the Unity Webapps Service introduces the concepts of Web application Contexts. A Context, is a handle dispensed by the Webapps Service, keyed by application name and domain (for example GMail, mail.google.com) which encapsulates the applications presence on the desktop. Primarly the Context Daemon has two responsibilities.

Firstly, the Context Daemon takes ownership of the applications resources, Music Players, Indicators, Launcher Quicklists, Icons, a .desktop file to identify the application, etc...

Secondly, the Context Daemon tracks it's "Interests", this maps to the idea of a 'view' of a web application. The Context knows about all it's interests, and can interact with them in various ways (raise an interest, request a screenshot, request the current location, etc...). When a context has no further interests, it is said to become "Lonely" and the Unity Webapps Service will eventually shut it down. This hierarchy of interests is exposed, and other Desktop clients (such as the Unity Shell) can use this information to interact with web applications (for example to show a list of Google Docs instances in the Desktop Application Switcher).

The Webapps Service itself is primarily responsible for handing out these contexts, and managing the lifespan of the daemons implementing individual contexts.