Resumen

  • Web Intents proponía que el navegador repartiera tareas entre servicios de la red. Un sitio podía pedir que se editara una foto sin señalar al editor; el usuario escogería el destino entre los servicios disponibles.
  • Chrome lanzó una prueba en su canal estable en 2012, pero los servicios solo podían inscribirse mediante manifiestos de aplicaciones de Chrome Web Store. Google desactivó el experimento desde Chrome 24, y el W3C cerró en 2013 el camino hacia una recomendación.

Una foto en busca de editor

El ejemplo de Chromium en agosto de 2011 era una pequeña empresa que guardaba fotos y necesitaba ofrecer edición. Podía construir su propio programa o pactar una integración con un proveedor concreto. Web Intents prometía otra cosa: la página describía la acción y entregaba los datos; el navegador buscaba un servicio capaz de realizarla. Compartir y visualizar también cabían en el diseño. La empresa de origen ganaría funciones sin negociar cada conexión por separado.

El documento del W3C describió al cliente que crea la solicitud, al servicio que se registra para una acción y un tipo de datos, y al navegador que empareja, entrega y devuelve la respuesta. Una página podía pedir «editar imagen» sin escribir la dirección de un editor. La especificación lo comparaba con el reverso de un enlace: el enlace fija el destino; la intención define la tarea. El destino pasaba a manos del usuario y de la interfaz del navegador.

El menú también reparte poder

Para que la idea funcionara, el navegador debía mantener un registro de proveedores y mostrar una elección comprensible. La propuesta exigía que la página del servicio declarase sus propias capacidades y que acción y tipo coincidieran con la petición. También requería un gesto del usuario antes de entregar una intención a un servicio descubierto. Un sitio cliente no podía consultar a escondidas la lista de servicios que la persona había configurado. Las preferencias podían ahorrar diálogos repetidos, pero el usuario tenía que conservar el control sobre la asignación.

El navegador adquiría así un puesto de intermediario. Decidía qué servicios aparecían, cómo se presentaban y cuándo cruzaban los datos de una página a otra. Para un editor de fotos, figurar en ese menú podía importar tanto como recibir una llamada comercial.

Un canal estable con puertas estrechas

El anuncio de mayo de 2012 situó una implementación experimental en la versión estable de Chrome. El adjetivo «estable» correspondía al canal del navegador. La API seguía marcada como experimental y podía cambiar de forma incompatible. Los servicios solo podían registrarse, de momento, desde el manifiesto de una aplicación de Chrome Web Store. Chromium esperaba levantar ese requisito más adelante. La demostración de un mercado abierto comenzó con una puerta controlada por la propia tienda del navegador.

Eso permitió probar el mecanismo con un conjunto acotado, pero no reprodujo el escenario en que cualquier servicio publicaba su capacidad y aparecía ante el usuario. La condición de entrada definía quién competía en la prueba.

El 1 de noviembre de 2012, Greg Billock comunicó al grupo del W3C que el soporte experimental quedaba desactivado desde Chrome 24. Su equipo veía trabajo pendiente en la API y en la experiencia de uso concreta de Chrome. No publicó una cifra de adopción ni atribuyó la retirada a un solo fallo. Había bastado medio año para pasar de la invitación a experimentar al cierre del interruptor.

La norma terminó en una nota

La nota del W3C del 23 de mayo de 2013 conservó el diseño y dejó constancia de que los grupos no continuarían hacia una recomendación. Tampoco habían hecho pruebas de interoperabilidad. El balance de junio de 2013 señaló dificultades sin resolver al integrar Web Intents en las interacciones del usuario. La idea de unir aplicaciones seguía teniendo un atractivo evidente. El punto decisivo era pedir a una persona que confiara una foto o un documento al servicio elegido en un menú ajeno.