Resumo

  • O Uniform Resource Agent reunia dados de ativação, alvos, experiência, roteiro de atividade e filtro de resposta em uma especificação durável, compartilhável e reexecutável.
  • A URAgency convertia a especificação em ação: mapeava o tipo para uma implementação, supria o ambiente de execução, ativava alvos locais ou remotos e interpretava retornos.
  • Guardar o objeto ou iniciar o programa não comprovava autorização, estabilidade semântica, execução correta, reprodutibilidade nem conclusão da tarefa.

O ponto de partida era separar o que o usuário precisava dos mecanismos escolhidos para atender à necessidade. Assinar uma lista, consultar serviços ou reunir resultados descrevia a atividade. URL, protocolo, script e página específica eram meios contingentes. Vincular tudo ao cliente fazia cada mudança externa se tornar uma mudança interna.

O URA era o registro persistente da atividade. Sua estrutura virtual tinha seis partes: cabeçalho de tipo; dados exigidos na ativação; alvos expressos por URL ou URN; experiência anterior, como data de execução e endereços já encontrados; script com condições, ordem ou agenda; e filtro que formatava ou avaliava a resposta.

Cada parte também abria uma decisão. Um campo preenchido não provava que o valor estava autorizado. Um alvo podia ser substituído por um espelho, por proximidade ou por uma URAgency remota. Experiência podia economizar trabalho e carregar premissas vencidas. O filtro podia promover um fragmento ou uma página de erro à condição de resultado.

A agência tornava o objeto executável

A URAgency anunciava os tipos aceitos, convertia implementações para a estrutura comum e de volta, conhecia o método de ativação e atendia às dependências. Um binário Pascal e um script interpretado podiam representar atividades semelhantes e ainda depender de cadeias de confiança diferentes. Portabilidade da especificação não significava equivalência dos runtimes.

Uma agência podia ser alvo; um URA podia chamar outro; um URA superior podia coordenar subordinados. A composição ampliava o controle distribuído: credenciais, bibliotecas, posição de rede, substituição de alvo e critério de conclusão podiam mudar a cada salto.

O protótipo Silk executava URAs em Tcl por uma interface de descoberta. Um exemplo fixava o endereço do serviço, enviava HTTP e analisava HTML por expressões regulares. Seus comentários admitiam tratamento de erro deficiente. Isso documenta uma implementação experimental, não adoção em escala.

Uma página para pessoas era uma API frágil

RFC 2016 alertou que uma mudança visual quase imperceptível para uma pessoa poderia quebrar o analisador. O artigo contemporâneo de Daigle e Mazzucato repete o diagnóstico. Entradas voltadas a máquinas ou agentes mantidos pelo provedor mitigariam o problema; não dariam validade permanente a objetos antigos.

O filtro exercia poder interpretativo. Um recibo de lançamento demonstrava início, não resultado. O fim do processo demonstrava encerramento local, não satisfação da necessidade. Reexecutar o mesmo URA podia resolver outro espelho, carregar outra biblioteca ou receber outro formato.

Publicado em outubro de 1996 como Experimental no Legacy stream, RFC 2016 sustenta a história de um experimento arquitetônico. Não sustenta adoção ampla nem uma linhagem direta até agentes de IA atuais. Sua contribuição histórica é mais rigorosa: ao tornar a intenção transportável, deixou claro que a autoridade de execução permanecia em algum lugar concreto.

Fontes