- From: James Hawkins <jhawkins@google.com>
- Date: Tue, 6 Dec 2011 10:00:36 -0800
*** Overview *** The W3C Web Intents Task Force is working on the Web Intents API at public-web-intents at w3.org: see the bottom of this email for details. Web Intents is a web platform API that provides client-side service discovery and inter-application communication. Services register to handle high-level actions (e.g., share, edit, pick), while clients invoke an intent (action + type + data). For example twitter.com may allow the user to register the site as a provider of the 'share' action. One of the critical pieces of the API is a declarative registration which allows sites to declare which intents they may be registered for. The current draft of the API calls for a new HTML tag, <intent>, the attributes of which describe the service registration: <!ENTITY % Disposition "{window|inline}"> <!ELEMENT INTENT - O EMPTY -- a Web Intents registration -> <!ATTLIST INTENT action %URI; #REQUIRED -- URI specifying action -- type %ContentTypes; #IMPLIED -- advisory content types -- href %URI; #IMPLIED -- URI for linked resource -- title %i18n; #IMPLIED -- service title -- disposition %Disposition window -- where the service is created -- > We settled on the <intent> tag after reviewing several alternatives (see below). The <intent> tag offers the greatest ease-of-use for developers, and the ability to crawl/index sites that support Intents. One of the cool things about the declarative syntax is that it allows one to create sites (like http://www.openintents.org/en/intentstable) which serve as a database of services that support intents. We're currently adding a section on webintents.org that allows the developer of a service to be add his service to the registry by entering the service URL, which we then crawl and index the intents. One could also imagine exposing intent services using search engine technology. *** Proposal *** Add the <intent> tag to the HTML spec. *** Alternatives *** Imperative DOM registration: registerIntentHandler(...). Pros: * Analogous to registerProtocolHandler, registerContentHandler. * Doesn't require addition to the HTML spec. Cons: * Not declarative, not as easy to index. * Timing requirements unclear (Is the registration removed if a service does not call registerIntentHandler() on the next visit? If so how long does the UA need to wait to 'be sure'?) * Heavier footprint in the DOM API. * Less self-documenting code: registerIntentHandler('webintents.org/share', 'text/uri-list', 'handler.html', 'My Sharer', 'inline'); <intent action="webintents.org" type="text/uri-list" href="handler.html" title="My Sharer" disposition="inline"> </intent> link rel="intents": Pros: * Declarative. Cons: * link rel has become a dumping ground for these type of usages. * Need to modify HTML spec to add appropriate attributes. CRX-less Web Apps (http://code.google.com/intl/en-US/chrome/apps/docs/no_crx.html): Pros: * Declarative. Cons: * Not standardized. * Requires extra level of indirection. *** API Status *** Within the W3C the Webapps WG is rechartering to include Web Intents as a joint-deliverable with the DAP WG (which already had Intents in its charter). Discussion is taking place about the API at public-web-intents at w3.org. The draft API is current hosted at [1], though I'm working feverishly to convert this into a W3C-style draft format. [1] https://sites.google.com/a/chromium.org/dev/developers/design-documents/webintentsapi Our use cases, JavaScript shim, and example pages are hosted at http://webintents.org. Thanks, James Hawkins
Received on Tuesday, 6 December 2011 10:00:36 UTC