Development

Differing intentions towards Web Intents

Developers from Google's Chrome team have merged support for Web Intents into the WebKit browser engine. That has the potential to give a big boost to the proposed web application inter-process communication (IPC) framework, which up till now has been largely theoretical — partly because, without browser support, there was little incentive for web developers to implement it. But the chicken-and-egg problem is not the only unsolved issue for Web Intents; the technology remains in nascent, draft form, with many people outside of the Chrome camp expressing concern over its completeness and its scope. Furthermore, Mozilla, which had been collaborating on the project in 2011, now seems to be headed in its own direction with its competing IPC framework.

Web Intents takes its name and broad strokes from Android's Intents IPC mechanism. The project is currently curated at the World Wide Web Consortium (W3C), with public discussion taking place on the public-web-intents mailing list.

Google Chrome and Chromium gained built-in support for Web Intents with the Chrome 18 release on March 29, although it still had to be activated with a runtime flag. Chrome 19, which arrived on May 15, enables this support by default. As a blog post on the subject explains, however, for the moment the only way for web developers to deploy a Web-Intents-speaking application is to publish it through the Chrome Web Store. That is because there is not yet an agreed-upon method for a web application to "register" that it understands Web Intents. The Chrome team would like to add an <intent> tag to HTML, but in the meantime the only solution is for the application to make its registration known through the Chrome Web Store's app manifest file.

Web Intents in a nutshell

The core concept of Web Intents is to permit lightweight IPC messaging between web applications during a browsing session, in order to cut down on interruptions to the user. Many people seem to find the nomenclature confusing, but in the project's parlance, an "intent" is an action that a user wants to perform — in other words, a function. The most frequently used example is a photo gallery site opening up an image in a separate photo editing site when the user clicks "Edit." In this scenario, the gallery application would call the EDIT intent on the image data:

    var intent = new Intent(Intent.EDIT, ‘image/png’, getImageDataURI());
    window.navigator.startActivity(intent, loadEditedImage);

without needing to know beforehand which other applications had declared themselves capable of handling EDIT for the image/png MIME type. Those various editing applications would have advertised their image-editing functions with:

    <intent
    action=”http://webintents.org/edit”
    type=”image/*”
    />

It is the browser's responsibility to notice the <intent> declarations, keep track of them, and provide some sort of UI for the user to select which application gets called when the "Edit" button is clicked. On the click, the browser clones the image object in memory, loads the editing web application of choice, and hands over the object for editing.

The specification lists seven default intents: discover, share, edit, view, pick, subscribe, and save. Each intent is intentionally broad; the action can have different meanings depending on the data type. For example, the share intent is discussed both for link-sharing (where it might replace the NASCAR-array of social media buttons) and for photo sharing (which in practice has fewer options than link sharing, plus a very different workflow). The Web Intents blog discusses many more, however, including calling a remote-printing service and calling a site-wide search using the browser's default search engine.

Open questions

On the discussion list and blog, the developers make it clear that despite the defaults intents list, they do not intend to strictly define a fixed set of acceptable intents. That position has led to quite a few questions about what exactly should be handled by an intent and what should not. One of the recurring questions is why an intent — which can pass any data structure from one browser frame to another — is better than other, existing methods for cross-site communication, such as postMessage, which do not require defining new HTML elements and DOM properties. Mozilla's Ben Adida wrote that combining postMessage and a small set of URI schemes (such as share://) would solve the same problems in a simpler fashion.

The generally cited answer is that Web Intents implement simple, generic operations between mutually-unknown web applications, while postMessage is used in full-blown APIs between sites that are designed beforehand to work together. But there is not a bright line distinction between the two use cases. In a lengthy thread from February, developer Greg Billock said "the problem web intents is trying to solve is more structured: 'how can web applications participate in fulfilling a single user-oriented task.'" But later in the same message, he says that Web Intents can be used to create generic message channels, and that "we're explicitly in favor of allowing generic connection establishment to exist alongside those more structured intents. "

John J Barton countered:

Barton also argued that the Web Intents specification is too vague to be implemented, and in particular leaves unaddressed the method by which a user would accumulate a set of options to handle any specific intent. In the image-editing example, for instance, when the user clicks "Edit" there must already be one or more third-party image editing web applications registered to handle the EDIT intent, or else browser cannot complete the command. "So you are counting on users to go around building up a list of useful services before they need them?"

Billock replied that there were three possibilities. First, that search engines will index sites that offer intents and build up registries of compatible applications to suggest. Second, that web application stores like the Chrome Web Store will highlight the intents of their listed applications. Or third, that the intent-"consuming" sites (such as the image gallery site in our example) will simply include links to compliant services that they recommend.

Mozilla's Web Activities

Last year, there were reports that Web Intents and Mozilla's similar Web Activities project would join forces. But that relationship was never formalized — in fact it may not ever have progressed beyond conversations between individual developers — and as of today, Mozilla seems to have dropped out of the Web Intents discussion. There is not a public position statement from Mozilla, but work on Web Activities is again progressing independently, spearheaded by the Mozilla WebAPI team that also tackles installable web apps and Boot-to-Gecko (B2G).

Mounir Lamouri posted a draft Web Activities specification in March, and updated it on May 23. The Web Activities proposal is narrower in scope than Web Intents. It discusses just three actions (share, edit, and pick), but it, too, asserts that any non-empty string should be considered a valid action. Nevertheless, in his proposal, Lamouri argues that Web Intents goes too far by trying to cover two-way, ongoing messaging between applications (citing the example Web Intents use case for remote-controlled video playback). That degree of interoperability should be handled by the site-specific APIs, he said, not be managed by the general-purpose Activities/Intents mechanism.

In Lamouri's proposal, an application declares its ability to handle a Web Activity with an activities {} property in its manifest file (rather than with a new HTML tag), a choice that the other Mozilla developers seem to agree on. The current Web Activities code — which is experimental and pre-dates the draft proposal — uses postMessage but it, too, is in an early stage of development. Lamouri said in an email that Mozilla's plan is to present Web Activities to the W3C Web Applications Working Group when it is finalized.

Ultimately the bigger story on Web Activities is not the specifics of the proposal, but the fact that Mozilla does not seem interested in collaborating with Google on Web Intents. It is noteworthy that Web Activities now falls under the purview of the WebAPI team, and the discussion around it revolves around B2G. B2G clearly needs an IPC mechanism compatible with its HTML5 application framework — and regardless of how trivial the example gallery-to-image-editor use cases seems on a desktop browser, it is also required by B2G's built-in camera and image editor.

Strangely silent on the Web Intents proposal is Apple, whose own Safari browser is also based on WebKit. Perhaps the company is just sitting out until the unanswered questions about the scope and implementation details get solid answers, but perhaps it sees Web Intents as a mechanism that interests Google only for use in its Apple-competing products like ChromeOS. Whatever the companies' underlying motivations are, users still have yet to put any of the competing options to the test on real world applications. With Web Intents in Chrome 19 and WebKit, at least they may soon get the opportunity.

Comments (4 posted)

Quotes of the week

— Darin McBride (on the Perl secret operators man page)

— Rob Weir

Comments (none posted)

libgit2 v0.17.0

libgit2 is a library for programmatic access to git repositories; the v0.17.0 release is out and, apparently, 1.0 is near. "Highlights on this release include diff, branches, notes and submodules support. The new diff API is shiny and powerful. Check it out."

Full Story (comments: none)

LLVM 3.1 released

Version 3.1 of the LLVM compiler suite is out. "This release represents approximately 6 months of development over LLVM 3.0, delivers a vast range of improvements and new features. Some of the most visible features include greatly expanded C++'11 support in Clang (including lambdas, initializer lists, constexpr, user-defined literals, and atomics); AddressSanitizer, a fast memory error detection tool which uses instrumentation to find bugs; "instruction bundles" support in the late code generator, allowing much better support for VLIW targets; an ARM integrated assembler which speeds up ARM compile time and enables new features for the ARM target; major enhancements to the MIPS backend (including support for MIPS64); a new port for the Qualcomm Hexagon VLIW processor, Python bindings, and much much more." See the release notes for details.

Full Story (comments: none)

Nmap 6 released

Version 6 of the nmap network scanner is out. "It includes a more powerful Nmap Scripting Engine, 289 new scripts, better web scanning, full IPv6 support, the Nping packet prober, faster scans, and much more." See the release notes for details.

Full Story (comments: 1)

ownCloud 4 released

Version 4 of the ownCloud "personal cloud" system is out. "ownCloud 4 – built through active community support – adds innovative features like file versioning, – which actively saves files, allowing users to “rollback” to previous versions – and a new API — giving developers an easy, stable and supported way to develop applications on top of ownCloud capabilities." It also adds support for direct opening of ODF documents and mounting of external filesystems like Dropbox or an FTP server. See the release announcement for more information.

Comments (15 posted)

Perl 5.16.0 released

The Perl 5.16.0 release is out. "Perl 5.16.0 represents approximately 12 months of development since Perl 5.14.0 and contains approximately 590,000 lines of changes across 2,500 files from 139 authors." See this article for an overview of what's new in this release.

Full Story (comments: 9)

Announcing printerd

Tim Waugh has announced (on May 10) the existence of the printerd project, meant to be a new print spooling subsystem for Linux. "It is a polkit-enabled D-Bus system service, written using the GLib object system. Although modeled on concepts from IPP (Internet Printing Protocol), printerd is not in itself an IPP server. Its only interface is D-Bus, although the aim is to be able to implement an IPP server on top of the D-Bus API as a separate process. Having a D-Bus interface means that applications wanting to print automatically get to use printerd asynchronously."

Comments (98 posted)

Development newsletters from the last week

• Caml Weekly News (May 22)
• What's cooking in git.git (May 20)
• Perl Weekly (May 20)
• PostgreSQL Weekly News (May 20)
• Ruby Weekly (May 17)
• Tahoe-LAFS Weekly News (May 19)

Comments (none posted)

A scientific basis for Open Source Software

Martin Davis of the JTS Topology Suite project points readers to an article in Nature arguing that open source software should be a standard requirement for peer-reviewed science. "The paper raises the argument for open source software to a higher plane, that of being a necessary component of scientific proof. It points out that the increasing use of computational science as a basis for scientific discovery implies that open source must become a standard requirement for documentation. Apparently some journals such as Science already require source code to be supplied along with submissions of articles."

Comments (49 posted)