Resumo

  • A ALIWEB deixou cada provedor de informação escolher o que descrever, mas manteve a coleta e a busca em um serviço central.
  • O piloto de 1994 mostra que outros catálogos podiam aproveitar um índice pequeno; não comprova cobertura integral da Web nem adoção ampla.

No fim de 1993, publicar um documento na Web já não bastava. Era preciso encontrá-lo sem percorrer servidor por servidor nem pedir a um robô que baixasse todas as páginas acessíveis. Listas manuais ofereciam contexto, mas seus responsáveis não conseguiam acompanhar cada mudança ou serviço novo. Um robô podia localizar mais recursos, ao custo de repetir requisições aos servidores e, às vezes, apagar a estrutura que dava sentido a uma coleção.

Em 30 de novembro de 1993, Martijn Koster anunciou a ALIWEB como um experimento de indexação “distribuída” da Web. Cada servidor anunciaria seu conteúdo em um arquivo local; um único site buscaria e processaria esses arquivos; depois, a base combinada poderia ser consultada pela Web. No artigo apresentado em conferência, Koster informa que o piloto no servidor da NEXOR operava desde outubro. No anúncio de 30 de novembro, Koster chamava o sistema de primeiro passo, não de solução definitiva, e deixava uma promessa importante: quando surgissem mecanismos melhores, os dados deveriam ser fáceis de reutilizar ou converter.

Essa promessa ajuda a entender a arquitetura. A ALIWEB não descentralizou o serviço de busca; distribuiu o controle sobre o índice. O administrador de cada site decidia quais documentos e serviços mereciam registro e escrevia a descrição. A equipe da ALIWEB mantinha a lista de servidores participantes, definia quando buscar cada arquivo, validava o formato, reunia os registros aceitos e operava a interface de pesquisa. O provedor descrevia o próprio site; o serviço central controlava o caminho que tornava essa descrição encontrável em outros lugares.

A entrada era um arquivo de texto preparado, muitas vezes chamado /site.idx, baseado em modelos do Internet Anonymous FTP Archives (IAFA). Esses registros de atributo e valor podiam descrever vários objetos em um mesmo arquivo: tipo do modelo, título, URI, descrição e palavras-chave, por exemplo. A ALIWEB não tentava deduzir o sentido de cada página a partir de sua marcação. Dava a quem conhecia a estrutura do site uma forma de destacar as entradas principais sem apagar a organização interna. O exemplo de Koster descreve o material de Perl da NEXOR e seu manual, não cada arquivo do servidor.

Participar ainda exigia um pequeno acordo operacional. O administrador registrava o servidor, a porta e o caminho do índice, informava um contato responsável e podia definir o intervalo mínimo entre coletas. A ALIWEB verificava se o arquivo existia e estava no formato esperado antes de aceitar o registro. Um processo separado, escrito em Perl, conferia os arquivos registrados, buscava as versões alteradas e reconstruía a base combinada por meio do cron do UNIX. O conteúdo podia ser pesquisado no formulário da própria ALIWEB ou integrado a outro catálogo, como o CUI W3 Catalog.

A diferença em relação a um robô que percorria toda a Web era prática, não absoluta. A ALIWEB automatizava a coleta e a consolidação, mas buscava um arquivo de índice indicado pelo administrador em vez de seguir cada link e baixar todos os documentos acessíveis no servidor. Isso reduzia o tráfego e preservava o contexto do provedor. Em contrapartida, uma página não incluída no índice podia ficar invisível mesmo que um robô conseguisse alcançá-la. A atualização dos resultados dependia do arquivo mantido pelo provedor, não apenas da coleta central.

Os números publicados por Koster mostram uso e limite ao mesmo tempo. Quando o artigo foi escrito, havia 54 hosts registrados e 310 itens na base. O formulário simples da ALIWEB recebia, em média, 80 consultas por dia; o CUI W3 Catalog recorria à base mais de 8 mil vezes por semana. Esses números comprovam um serviço em funcionamento e uma integração útil. Não medem a parcela da Web indexada, a qualidade dos resultados ou quantos servidores podiam ou queriam manter um arquivo válido.

A dificuldade de adesão apareceu cedo. Alguns administradores registravam o host sem enviar um índice, aparentemente porque chegavam ao formulário sem compreender o mecanismo. A equipe ampliou a documentação e passou a verificar imediatamente a presença e o formato do arquivo. Ainda havia erros: eles eram registrados, e um script executado manualmente avisava o contato responsável por e-mail. A manutenção não desaparecia na descentralização; mudava do rastreamento de cada página para a criação, a validação e a atualização de um índice selecionado.

“Manual” também não precisava significar que alguém digitaria cada linha para sempre. Koster considerava aceitável gerar o arquivo por software, desde que ele preservasse metadados suficientes para orientar a busca. Em 1995, outro projeto de arquivo documentou modelos IAFA atualizados a partir das mudanças no sistema de arquivos e usados para produzir índices em texto, Gopher e HTML. Esse artigo da conferência do W3C mostra que o formato podia alimentar diferentes interfaces; não prova que o acervo da ALIWEB tenha migrado nem que o serviço tenha sido adotado em larga escala.

A escala expunha um segundo limite. Koster reconhecia que uma base única para toda a Web poderia ficar grande demais. Como alternativas, propôs distribuir a coleta, espelhar o acesso à pesquisa, separar bases por assunto ou criar uma hierarquia de serviços ALIWEB. Também esperava que os arquivos pudessem ser convertidos automaticamente para futuros sistemas de diretório. Eram possibilidades apresentadas no artigo, não recursos comprovadamente implantados. O ponto histórico é que o formato deveria sobreviver ao coletor central do piloto.

Um levantamento de 1994 sobre recuperação de informação em rede ainda descrevia um campo jovem, no qual classificação e outros recursos não eram amplamente usados. A ALIWEB coexistia com listas manuais, com o CUI W3 Catalog e com buscas por robôs, como a JumpStation e a base de URLs da RBSE; não foi a primeira ferramenta de busca da Web. Sua contribuição mais precisa foi mostrar como descrições selecionadas na origem podiam ser coletadas automaticamente e reutilizadas por outros sistemas.

A Nota 65 de Heng Lu sobre a primazia do código em execução serve como lente retrospectiva, não como evidência sobre o que Koster pensava: um formato pode prometer portabilidade, mas só sistemas que o adotam e executam tornam essa promessa real. O artigo documenta o piloto da ALIWEB e o uso de sua base pelo W3 Catalog. Não documenta adoção universal, autoridade sobre os editores da Web nem uma migração concluída. A distinção importante tem três partes: provedores decidiam o que seus sites diziam; a ALIWEB decidia o que entrava no índice compartilhado; sistemas futuros podiam reutilizar o arquivo sem herdar o serviço central do piloto.