Zusammenfassung

  • Web Intents wollte dem Browser die Vermittlung zwischen Webdiensten übertragen. Eine Seite stellte die Aufgabe „Foto bearbeiten“ oder „Link teilen“, ohne den Anbieter festzulegen; der Nutzer wählte aus passenden Diensten.
  • 2012 erreichte ein Experiment den stabilen Chrome-Kanal, doch Dienste konnten sich zunächst nur über App-Manifeste des Chrome Web Store anmelden. Ab Chrome 24 war die Funktion deaktiviert. W3C beendete 2013 die Arbeit an einer Empfehlung.

Ein Foto brauchte einen Bearbeiter

Chromium beschrieb im August 2011 eine kleine Fotoplattform, der das Geld für einen eigenen Editor fehlte. Sie konnte einen Editor bauen oder mit einem konkreten Anbieter eine Schnittstelle vereinbaren. Web Intents versprach einen anderen Weg: Aufgabe und Bild an den Browser übergeben, der dann einen geeigneten Dienst vermittelt. Teilen und Anzeigen gehörten ebenfalls zum Entwurf. Eine kleine Seite sollte Funktionen bekommen, ohne jeden Dienst einzeln einzubauen.

Die W3C-Fassung trennte Client-Seite, Dienst-Seite und User Agent. Der Client formulierte eine Aktion, einen Datentyp und Nutzdaten. Dienste meldeten unterstützte Kombinationen an. Der Browser verglich sie, ließ den Empfänger wählen, lieferte die Daten aus und brachte gegebenenfalls das Ergebnis zurück. Ein Link nennt sein Ziel schon beim Setzen. Ein Intent nennt zunächst die Arbeit. Das Ziel wird danach bestimmt. Damit verlagerte sich eine wichtige Entscheidung von der Ausgangsseite in den Browser.

Der Vermittler braucht eine Gästeliste

Der Entwurf schrieb vor, dass ein Dienst nur eine Handler-Seite seiner eigenen Herkunft registrieren konnte. Aktion und Datentyp mussten zur Anfrage passen. Bevor ein neu entdeckter Dienst Daten erhielt, war eine konkrete Handlung des Nutzers nötig. Die aufrufende Seite durfte die vom Nutzer eingerichteten Dienste nicht heimlich abfragen. Der Browser konnte Präferenzen speichern, damit die Auswahlliste nicht jedes Mal erschien, doch der Nutzer musste die Zustellung steuern können.

Hier lag der wirtschaftliche Einsatz. Die Fotoseite wollte Bearbeitung ohne exklusive Partnerschaft. Jeder Editor wollte im Menü auftauchen. Der Browser bestimmte Anmeldung und Anzeige. Der Mensch musste erkennen, wohin sein Bild ging. Die Oberfläche war zugleich Marktordnung und Vertrauensfrage.

Ein Experiment im stabilen Kanal

Laut Chromiums Ankündigung vom Mai 2012 lief eine experimentelle Version im damals aktuellen stabilen Chrome. Das API hatte weiterhin ein Präfix; inkompatible Änderungen waren möglich. Dienste durften sich vorerst nur in einem App-Manifest des Chrome Web Store registrieren. Später sollte diese Hürde fallen. Der geplante offene Vermittlungsplatz begann mit einem Zugang über den eigenen Store des Browsers.

Die Begrenzung machte die Erprobung handhabbar. Sie begrenzte auch, was die Erprobung über einen offenen Markt zeigen konnte. Eine beliebige Dienst-Seite konnte nicht einfach die im W3C-Text vorgesehene Markierung veröffentlichen und im laufenden Chrome neben anderen Anbietern erscheinen.

Am 1. November 2012 erklärte Google-Ingenieur Greg Billock in der öffentlichen W3C-Liste, Chrome habe die experimentelle Unterstützung ab Version 24 deaktiviert. Das Team habe sowohl am API als auch an der konkreten Chrome-Bedienung weiteren Entwicklungsbedarf gefunden. Die Nachricht enthielt weder Nutzerzahlen noch einen einzelnen Fehler als Erklärung. Der wenige Monate zuvor gestartete Versuch war beendet.

Das Papier blieb, die Empfehlung fiel aus

Die W3C-Arbeitsgruppennotiz vom 23. Mai 2013 bewahrte den Entwurf und vermerkte zugleich, dass die Gruppen ihn nicht weiter als Empfehlung entwickeln würden. Interoperabilitätstests hatten sie nicht durchgeführt. Der W3C-Bericht vom Juni 2013 benannte ungelöste Probleme bei der Einbettung in Nutzerinteraktionen. Dienste zu verbinden war eine sinnvolle Aufgabe. Schwierig war die glaubwürdige Wahl des Empfängers genau in dem Moment, in dem Daten die Seite verließen.