Development

A look at the Crosswalk web runtime

At the 2014 Tizen Developer Summit in Shanghai, Sakari Poussa presented an overview of Crosswalk, the web runtime designed to support Tizen's HTML5 application framework. Crosswalk builds on work from the Blink rendering engine and several other projects, but its goal of serving as a web-app runtime system makes for several distinctions with projects designed for use as a browser.

The web runtime is responsible for managing and running HTML5-and-JavaScript applications. In that sense, it serves a role that is similar to that of any web browser, but differs in some key areas. In web apps, the user does not have access to many (or any) of the normal user interface "chrome" or controls that comprise the basic interaction model of a standard browser. In addition, on mobile devices, the web runtime's support for hardware-access APIs is significantly more important, and it is responsible for starting, loading, and shutting down multiple app process at any given time.

Up through the Tizen 2.x series, Tizen releases shipped a web runtime based on WebKit. Crosswalk was started in September 2013, after Google forked its WebKit code into the Blink project. Currently, Poussa explained, new Crosswalk releases are made approximately once every six weeks, after the corresponding Blink release. The Crosswalk team attempts to push its own changes upstream, so that it can periodically rebase on Blink and minimize divergence. There are three Crosswalk release "channels"—Stable, Beta, and Canary (the unstable channel).

In addition to running on Tizen, Crosswalk builds are intentionally released for Android as well, with the goal of making the runtime fully cross-platform. Poussa said that the team is interested in seeing Crosswalk put to use in other open-source projects. That could mean other Linux-based mobile operating systems in need of a web-app runtime, but the Crosswalk implementation of newer APIs could prove useful to other Blink- and WebKit-related work as well.

Although it is easy to describe Crosswalk as "based on Blink," Poussa noted that the runtime also pulled in pieces of several other upstream projects, including Chromium, FFmpeg, the Skia graphics library, the V8 JavaScript engine, and the Cordova Android library. On top of these components are the Crosswalk-specific modules, such as the web-app manifest parser, the app runtime model, the app security framework, Tizen's implementation of the W3C System Applications (SysApps) APIs, and a framework for JavaScript extensions.

APIs

The SysApps APIs, manifest parser, and security framework are all pieces used to hook an HTML5 web app into Tizen's application framework. While some of the Tizen device profiles (such as the smartphone profile) also support native applications through another framework like EFL, not all do—but the HTML5 framework is common to every profile.

Thus, Crosswalk has quite a few HTML5 APIs that it needs to support. Poussa said that the project embraces the W3C APIs, but that it also serves as a "landing zone" for new draft APIs (some of which might undergo significant revision before stabilizing). As of now, he reported, Crosswalk ranks the highest on HTML5test's table of HTML5 API compatibility.

Poussa outlined six new features in Crosswalk that were not supported in the old Tizen web runtime. They include Web Components (encapsulated, reusable bundles of custom HTML elements), Service Workers (background JavaScript processes), support for Native Client code, web-app manifests, and two broader feature categories: SysApps and responsive design. The SysApps APIs incorporate several separate pieces related to integrating web apps into the OS platform, such as an API for querying device capabilities, a URI scheme for locally installed apps, and raw network sockets. The responsive design features include support for CSS media queries, the @viewport CSS rule, and the <picture> element (which can specify multiple images source to be used under various circumstances).

In addition, Crosswalk adds support for quite a few new APIs that have only recently become implementable standards, such as Promises (a method to asynchronously reply to resource requests), Resource Timing (for measuring the latency of loading a page resource), User Timing (for timestamping events), Ambient Light, Gamepad, NFC, JavaScript SIMD, WebRTC, Web Animations, and HTML5 Input.

The Tizen 2.x web runtime did ship an NFC "implementation," he noted, but it was a proprietary one, not the W3C standard. Compatibility with Tizen 2.x's runtime is an ongoing concern, he explained. The project is explicitly maintaining 2.x compatibility to ensure that existing web apps continue to function as expected. In addition, the project maintains compatibility with several outside products, such as Intel's XDK and Apache Cordova.

Architecture

Poussa then discussed Crosswalk's architecture. Tizen uses Smack as its security framework, with a significantly simplified, three-domain security policy in the 3.0 series. The Cynara service enforces the security policy, brokering API requests from the apps and checking them against the Smack policy to see if the app has the necessary permissions. Currently, he said, the Smack policy enforces a permission check on all APIs that access the hardware (including the Tizen Device API plus all W3C and experimental APIs that are hardware related). The permissions granted to each individual app are computed at installation time, based on the app's configuration file. Attempts to access anything outside of those permissions are met with a denial from Cynara.

When running on a device, Poussa explained, there is one shared Crosswalk browser process at all times. Each web app spawns a new Blink rendering process of its own and an extension process, so that each app is isolated from the others. These app processes talk to the base browser process via inter-process communication (IPC). The browser process talks to the operating system through the usual mechanisms, such as D-Bus or Unix domain sockets.

An audience member asked how the shared process related to the individual app processes as far as the Smack policy was concerned. In particular, he wondered if the shared process had permission to access all APIs, which might sound like a security risk. Poussa referred the question to Smack maintainer Casey Schaufler, who was also at the session. Schaufler replied that each installed app has its own Smack label, and that the policy rules and the Cynara permission checks were bound to these per-app labels, not to processes.

That explanation did not seem to fully satisfy the questioner, but in the interest of time, Schaufler encouraged him to attend the security session the following day rather than steer the current session off on a lengthy tangent. Despite being the Simplified Mandatory Access Control Kernel, it does seem like many developers have yet to get accustomed to how Smack works in Tizen.

Two other questions from the audience asked for clarification on the raw sockets API and on graphics. Raw sockets, Poussa explained, have been part of a long and slow specification process with the W3C, but the concept is fairly simple: the web app can connect to a general-purpose socket to communicate with another process—the other end of the connection never even knows that it is talking to a web app. The graphics layer uses Ozone, which supports multiple backends. One of those backends is Wayland (which is used by Tizen IVI), but there are other options that may be better suited to other device profiles, such as the hardware-accelerated framebuffer.

In the grand scheme of things, Poussa said, Intel wants Crosswalk to differ from the old, WebKit-based runtime in several key ways. The first is that everything will be done in the open: no code drops or private mailing lists. The team tries hard to keep a balance between implementing new features in Crosswalk and implementing them in the upstream projects first—only when time constraints are a pressing issue, he said, would work start in Crosswalk's branch of an upstream project.

The project also wants to close the gap between native app performance and web app performance, which is why some features (such as raw sockets and Native Client) are so important. In response to an audience question, Poussa said that Crosswalk developers have found Google's Blink project far more suitable for these goals than WebKit was. In WebKit, he explained, the project leadership was adamant that certain features do not belong in the rendering engine, and drew sharp lines that could not be crossed. In Blink, Google is implementing a wider feature set, which in turn makes it easier to extend Crosswalk's functionality.

Commercial Tizen 3.0 devices have yet to hit the market, of course, but Crosswalk could be useful to other open-source projects as well, Poussa said. Participation from non-Intel contributors has risen considerably in recent months, he said, which is a good sign. Regardless of when it reaches the masses, though, Crosswalk remains an interesting testbed for an HTML engine specifically targeting web-app deployment, rather than general browsing.

In many ways, the only major competitor to Crosswalk on today's Linux-powered mobile devices is the Gecko engine used in Mozilla's Firefox OS, although Android has been adding support for web apps as well. At the moment, there do not seem to be any projects other than Tizen making use of Crosswalk, but as interest in up-to-date web runtimes increases on a variety of platforms, that situation could change. At the very least, the competition is likely to be a motivating factor for most of the projects.

[The author would like to thank the Tizen Association for travel assistance to attend TDS 2014.]

Comments (none posted)

Quotes of the week

— Aaron Boxer (hat tip to Mattias Mattsson)

— Keith Packard, on the ups and downs of the e-book marketplace.

Comments (2 posted)

systemd 217 available

Version 217 of systemd has been released. New in this update are the ability for services to notify the manager before they begin a reload, the addition of a user-console daemon, and the removal of user-space firmware loading functionality.

Full Story (comments: none)

Development newsletters from the past week

• What's cooking in git.git (October 24)
• What's cooking in git.git (October 28)
• Haskell Weekly News (October 22)
• LLVM Weekly (October 27)
• OCaml Weekly News (October 28)
• OpenStack Community Weekly Newsletter (October 24)
• Perl Weekly (October 27)
• PostgreSQL Weekly News (October 26)
• Python Weekly (October 23)
• Ruby Weekly (October 23)
• Tor Weekly News (October 29)
• Wikimedia Tech News (October 27)

Comments (none posted)

Schaller: GStreamer Conference 2014 talks online

On his blog, Christian Schaller announced the availability of videos from the recently completed GStreamer Conference. "For those of you who like me missed this years GStreamer Conference the recorded talks are now available online thanks to Ubicast. Ubicast has been a tremendous partner for GStreamer over the years making sure we have high quality talk recordings online shortly after the conference ends. So be sure to check out this years batch of great GStreamer talks."

Comments (none posted)

Taiga, a new open source project management tool with focus on usability (Opensource.com)

Opensource.com takes a look at the Taiga project management tool. "It started with the team at Kaleidos, a Madrid-based company that builds software for both large corporations and startups. Though much of their time is spent working for clients, several times a year they break off for their own Personal Innovation Weeks (ΠWEEK). These are weeklong hack-a-thons dedicated to personal improvement and prototyping internal ideas of all sorts. While there, they unanimously decided to solve the biggest of their own problems: project management. Taiga was born, and by early 2014, the team at Kaleidos was already using Taiga for all their internal projects. Taiga Agile, LLC was formed in February 2014 to give the project a formal structure, and the source code was made available at GitHub."

Comments (5 posted)

Season of KDE 2014

The Season of KDE is a community outreach program, much like Google Summer of Code. "It is meant for people who could not get into Google Summer of Code for various reasons, or people who simply prefer a differently structured, somewhat less constrained program. Season of KDE is managed by the same team of admins and mentors that takes care of Google Summer of Code and Google Code-in matters for KDE, with the same level of quality and care." The student application deadline is October 31. The mentor application deadline is November 5.

Comments (3 posted)