LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DevelopmentDiffering intentions towards Web IntentsDevelopers 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 nutshellThe 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 questionsOn 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:
To be realistic, web-intents arranges for "uni-directional string-
augmented MIME type communications". If we [are] lucky the communications
will fulfill a task. The primary and important advantage of the web-intent
approach is that the tasks allowed by the communications are simple to
characterize and MIME types describe digital properties interesting to
many users.
If the user-oriented task involves interactivity or non-MIME data, then their task won't be fulfilled. 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 ActivitiesLast 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.
Brief items Quotes of the week
I'd like to make a couple of
(minor?) suggestions:
— Darin McBride (on the Perl
secret operators man page)
1. Label the "secret" operators that are encouraged (Venus, Bang bang, Eskimo greeting, and maybe Babycart, I think) to distinguish them from the "obscure to the uninitiated".... 2. I know what =()= is normally called. But as soon as you put "don't google this", you know what's going to happen. At a bare (no pun intended) minimum, it should be labelled as Not Safe For Work.
Conflict sells news stories. "OpenOffice and LibreOffice volunteers
work together on Community Support Forums" will never make a new
story. But 'Rob Weir Farts During Playing of LibreOffice National
Anthem" will be headline news and will be retweeted 100 times.
— Rob Weir
libgit2 v0.17.0libgit2 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."
LLVM 3.1 releasedVersion 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.
Nmap 6 releasedVersion 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.
ownCloud 4 releasedVersion 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.
Perl 5.16.0 releasedThe 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.
Announcing printerdTim 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."
Newsletters and articles Development newsletters from the last week
A scientific basis for Open Source SoftwareMartin 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."
Page editor: Jonathan Corbet |
|||||||||||||