Resumo

  • Web Intents propunha um balcão de serviços administrado pelo navegador. Um site pedia a edição de uma foto sem escolher de antemão o editor; a pessoa selecionava um serviço capaz de fazer o trabalho.
  • O Chrome levou a experiência ao canal estável em 2012, mas restringiu o cadastro de serviços a manifestos de aplicativos da Chrome Web Store. O suporte foi desativado a partir do Chrome 24. Em 2013, o W3C encerrou o caminho até uma Recomendação.

O trabalho existe; falta quem o faça

Em agosto de 2011, a equipe do Chromium imaginou um pequeno site de fotos que queria oferecer edição sem financiar um editor próprio. A alternativa costumeira era construir a ferramenta ou integrar-se a um fornecedor específico. Web Intents trocaria o acordo prévio por um pedido de tarefa: editar esta imagem, compartilhar este endereço, visualizar este arquivo. O navegador faria a ponte com um serviço apto a responder. Para empresas pequenas, o apelo era escapar do custo de integrar cada parceiro à mão.

O projeto do W3C distribuía funções entre a página cliente, a página do serviço e o navegador. A primeira enviava uma ação, um tipo de dado e um conteúdo. O serviço anunciava o que sabia processar. O navegador comparava os dois, apresentava a escolha e devolvia a resposta. Um link normal já traz seu destino. O Intent descrevia a tarefa e deixava o destino para a escolha posterior. Isso retirava do site de origem uma decisão comercial importante.

A lista de opções tem dono

O desenho precisava responder quem poderia aparecer como serviço. O texto exigia cadastro na mesma origem da página de atendimento, correspondência entre ação e tipo de dado e um ato específico do usuário antes da entrega a um serviço descoberto. A página que iniciava o pedido não podia descobrir silenciosamente quais serviços o visitante havia configurado. Preferências poderiam reduzir a repetição do seletor, mas a pessoa deveria controlar o encaminhamento.

O navegador se tornaria porteiro e apresentador de um mercado. Um editor de fotos gostaria de figurar quando o usuário procurasse editar. O site de fotos gostaria de oferecer a função sem depender de um parceiro. A pessoa precisaria saber para onde sua imagem seria enviada. A interface de escolha condensava essas três disputas.

Um teste estável com entrada estreita

O anúncio de maio de 2012 dizia que uma implementação experimental estava disponível no Chrome estável. A API continuava marcada por um prefixo e poderia mudar sem preservar compatibilidade. O cadastro de serviços, naquela versão, só funcionava por meio do manifesto de um aplicativo da Chrome Web Store. Chromium pretendia retirar a restrição quando a API amadurecesse. A proposta de conectar serviços da web sem acordos fechados começava com uma porta controlada pela loja do navegador.

Essa limitação facilitava testar o mecanismo, mas não permitia observar a concorrência de qualquer página de serviço publicada na web. O conjunto de opções já chegava filtrado pela forma de inscrição.

Em 1º de novembro de 2012, Greg Billock informou à lista pública do W3C que o Chrome havia desativado o suporte experimental a partir da versão 24. A equipe identificara pontos a desenvolver na API e na experiência específica de uso do navegador. O comunicado não trouxe número de usuários nem um defeito único. A demonstração aberta aos desenvolvedores poucos meses antes havia chegado ao fim.

Uma nota no lugar da norma

A nota do W3C de 23 de maio de 2013 preservou o projeto e registrou que os grupos não seguiriam até uma Recomendação. Também informou que não houve teste de interoperabilidade. O balanço do W3C de junho de 2013 apontou dúvidas ainda abertas sobre a integração do sistema às interações do usuário. Havia serviços a conectar. Faltava uma maneira convincente de mostrar a escolha e obter confiança antes de enviar dados entre sites.