BBS-RIA: Um BBS Multimédia baseado no WWW

António Costa * , Fausto de Carvalho**, Lusitana Fonseca**,
Martinho Marinheiro**, Rui José*, Vasco Freitas*

Departamento de Informática*
Universidade do Minho
4700-320 Braga

Tel.: +351 253 604475
Fax.: +351 253 604471
E-mail: {costa, rui, vf}@di.uminho.pt

Direcção Central de I&D**
CET, Portugal Telecom
Rua Eng. José Ferreira Pinto Basto
3800 Aveiro

Telef.: +351 234 381831
Fax.: +351 234 20722
E-Mail: {cfausto,lusitana,martinho}@cet.pt


Resumo

O World Wide Web abre caminho a um vasto conjunto de aplicações emergentes. Mas cria também novos desafios e perspectivas a aplicações mais tradicionais como os Bulletin Board Systems ou BBSs. O Centro de Estudos de Telecomunicações e a Universidade do Minho estão a desenvolver o projecto de um BBS baseado em tecnologia WWW. Este projecto a funcionar num ambiente RDIS é o elemento central dos Demonstradores de Tecnologias e Serviços da Portugal TELECOM.

A ideia chave em que assenta todo o desenvolvimento realizado é uma ideia de comunidade de utilizadores acedendo a uma série de serviços de forma integrada.

A solução utilizada na criação do BBS, designado BBS-RIA, consiste em utilizar o protocolo HTTP para a comunicação e as páginas HTML para a representação dos boletins e outros documentos. Desta forma qualquer Browser WWW torna-se num potencial cliente do BBS.

O BBS encontra-se organizado por fora temáticos cada um com o seu coordenador e um conjunto definido de utilizadores. Dentro desses fora encontram-se três áreas distintas embora relacionadas entre si: a área de boletins informativos, a área de conferências baseada em mensagens multimédia e, por fim, a área de ficheiros.

O elemento central do sistema é um servidor HTTP complementado com um CGI responsável pela implementação de todos as funcionalidades específicas do BBS. Apresentam-se e discutem-se os mecanismos que tiveram de ser introduzidos para contemplar os requisitos próprios de um ambiente de exploração comercial do BBS.

A instalação do sistema está actualmente em curso. Nele estão envolvidos utilizadores experimentais de diversas Universidades, Escolas, Empresas, instituições públicas e privadas.

Keywords: WWW, Aplicabilidade, BBS, Educação,RDIS


1. Introdução

1.1 Demonstradores de Tecnologias e Serviços

O CET tem investido grande quantidade de recursos na área de investigação de novos serviços de telecomunicações e do desenvolvimento de novas aplicações neles baseados, na perspectiva de que um conjunto de actividades das empresas e instituições, quer no sector público quer no sector privado, possam utilizar num futuro próximo, as telecomunicações avançadas como suporte para a modernização de métodos e processos e como contributo para a racionalização de recursos e meios.

A introdução de sistemas informáticos sobre a rede de Telecomunicações no ambiente empresarial, das instituições e do sector privado em geral, tem um papel importante na revitalização socio-económica das empresas e instituições sendo ainda determinante, para o sector residencial, o seu impacto nos serviços recreativos, de educação, saúde, assistência social e trabalho à distância.

Para descobrir e construir novos serviços de telecomunicações dirigidos a novas utilizações é fundamental a participação dos futuros utilizadores, que poderão contribuir desde o Inicio para a construção de produtos e serviços adaptados às suas funções e necessidades.

Trata-se de estimular e antecipar mercados para novos produtos e serviços de Telecomunicações projectados para responder às necessidades de novos clientes, que colaborando nestes processos de inovação, ganham a perspectiva da utilização das telecomunicações como vector determinante do desenvolvimento socio-económico e cultural da sociedade.

No âmbito dos Demonstradores de Tecnologias e Serviços, as redes avançadas de Telecomunicações permitem a um conjunto restrito de utilizadores, escolhidos de acordo com o tipo de projecto, participar e contribuir para o desenvolvimento de novos serviços.

O CET seleccionou um conjunto de utilizadores experimentais que já participam ou vão participar em futuras acções no âmbito dos DT&S com os quais estabeleceu protocolos de cooperação.

Projectos específicos, onde a avaliação de factores humanos e sociais bem como a determinação do impacto sócio económico nas actividades das empresas e instituições tem um papel tão importante como o da introdução de novas tecnologias de telecomunicações, são normalmente acompanhados e desenvolvidos em cooperação com Universidades e Institutos de I&D nacionais e europeus que partilham com o CET actividades de carácter técnico e científico integradas nos seus planos de trabalhos e áreas de interesse.

É neste contexto e como projecto de investimento partilhado que o BBS-RIA tem sido desenvolvido pela Universidade do Minho e pelo CET, com a participação dos utilizadores dos fora nas tarefas de Especificação, Operação e Avaliação.

1.2 BBS-RIA: Um projecto de Comunicação nos DT&S

Como responsável pela implementação dos DT&S o CET tem a seu cargo a instalação, operação e manutenção dos Serviços e complementarmente a responsabilidade pela criação dum ambiente de investigação participada onde estão envolvidos os parceiros naturais: Universidades e Institutos de I&D e a componente fundamental representativa dos ambientes de utilização: Escolas, Empresas, Hotéis, Administração Pública, Residenciais, Instituições Públicas e Privadas.

A necessidade de criar ambientes de comunicação estimulantes e apelativos conduziu os parceiros ao enunciado de propostas de ambientes de debate e de construção de bases de informação úteis e participadas de modo a garantir a curto prazo a contribuição e construção de grandes blocos de informação temática, com crescimento aberto e progressivo.

As propostas assumiram assim o carácter de fora temáticos adequados a Escolas, Empresas, Comunidade pública em geral e Instituições. A necessidade de correio electrónico e transferência de ficheiros enunciou-se logo como complementarmente necessária.

A exigência de fazer opções abertas e evolutivas permitindo o acesso intuitivo e a manipulação de documentos multimédia foi desde logo o ponto de partida para a especificação de um BBS integrador de todas as funcionalidades, acrescido do facto de ser suportado em comunicações ISDN e/ou POTS.

Os fora têm a seu cargo a identificação, organização e classificação da informação que posteriormente irá contribuir para cada área temática. São eles ainda que vão organizar os serviços nas Escolas, Empresas e Instituições de modo a preparar a integração da operação do BBS na sua normal actividade.

Espera-se que a operação permita posteriormente refinar as funcionalidades pelo natural aparecimento de novos requisitos. O BBS será assim um sistema em evolução que poderá conter, após validação, os componentes necessários para garantir a sua evolução para a fase pré-comercial, recorrendo às provas já dadas pelo serviço Internet e estimulando a utilização dos serviços de telecomunicações avançados de forma inovadora.

Do ponto de vista da contribuição esperada para a revitalização social e económica, é esperado que os microcosmos que são os DT&S permitam avaliar o impacto deste tipo de serviços para a circulação e abertura de informação aos meios empresariais, escolares, residenciais, administrativos e institucionais e evidenciar os potenciais benefícios desta capacidade de comunicação.

2. Infraestrutura de telecomunicações

O Demonstrador de Tecnologias e Serviços tem como suporte físico a rede RDIS [1] [2] (Rede Digital com Integração de Serviços). Esta tecnologia disponibiliza dois tipos de acessos: o acesso básico que permite a utilização simultânea de 2 canais de 64Kbps e o acesso primário que possibilita a utilização de 30 canais de 64Kbps. A RDIS é totalmente digital até à casa do assinante e não é mais do que a evolução natural da rede telefónica actual sendo completamente compatível com esta a nível dos serviços.

Foi instalada em Aveiro uma rede RDIS experimental recorrendo a um comutador de tecnologia nacional, ELDIS (Estação Local Digital com Integração de Serviços) desenvolvida no CET e que serve de base ao DT&S. Esta rede foi alargada a Braga, Mangualde, Coimbra e Lisboa de modo a permitir o acesso aos parceiros envolvidos nos DT&S. A Figura 1 apresenta um diagrama simplificado da infraestrutura utilizada pelo BBS RIA.

Figura 1 : Arquitectura do demonstrador

O demonstrador é constituído por uma rede local LAN RIA onde está localizado fisicamente o BBS RIA. Existe a possibilidade de activar um router de acesso à Internet de modo a permitir o acesso por esse meio. O acesso via RDIS é feito por intermédio de um router (Router S2M) que pode atender simultaneamente até 30 ligações podendo ser estas dial-up (originadas pelos terminais RDIS RIA) ou dos routers 3S0 e por isso fazendo interligação de redes e permitindo o acesso dos terminais LAN RIA aí presentes. Os terminais RDIS RIA são PCs que dispões de uma carta RDIS e do software necessário para acesso ao BBS (pilha TCP/IP sobre RDIS, cliente WWW).

3. Requisitos do BBS-RIA

Os requisitos do BBS-RIA podem ser agrupados segundo duas perspectivas distintas: a dos utilizadores, preocupados em como o sistema lhes permitirá de facto usufruir de um ambiente de comunicação à sua medida, e a perspectiva da exploração dos serviços por parte de uma entidade com preocupações de gestão e organização do serviço. Muitos dos requisitos deste segundo grupo são fundamentais para satisfazer os primeiros.

3.1 Sob o ponto de vista do utilizador

O processo de elaboração de requisitos iniciou-se com consultas aos participantes no demonstrador e futuros utilizadores do BBS. Dos grupos de trabalho temáticos formados produziu-se uma especificação funcional pormenorizada [3], da qual se podem destacar alguns aspectos mais importantes.

O BBS encontra-se organizado por fora temáticos cada um com um conjunto definido de utilizadores e um coordenador que atribui privilégios a esses utilizadores. Dentro de cada forum encontram-se três áreas distintas embora relacionadas entre si:

Complementarmente à actividade dos fora pretende-se igualmente disponibilizar correio electrónico inter-pessoal.

Uma ideia essencial da especificação funcional é o acesso aos diferentes serviços de forma integrada. Ou seja, independentemente dos protocolos utilizados, o utilizador pretende ter um único interface que lhe forneça uma visão integrada das diferentes áreas do BBS.

3.2 Sob o ponto de vista da exploração do serviço e do desenvolvimento

A satisfação dos requisitos anteriores, num eventual ambiente de exploração comercial, exige, por sua vez, um conjunto fundamental de facilidades adicionais básicas [4], como sejam:

4. Arquitectura do Sistema

Embora a hipótese de recorrer a pacotes de programas específicos para BBS tenha sido considerada optou-se por basear a arquitectura do sistema em tecnologia WWW [5] sendo os boletins e outros documentos representados por páginas HTML [6]. O WWW, para além de permitir satisfazer os principais requisitos colocados nomeadamente ao nível das capacidades multimédia, tem um importante argumento a favor da sua utilização: o facto de se tratar de uma tecnologia cada mais divulgada e de importância crescente donde resultam algumas vantagens importantes como sejam:

Tendo em conta os requisitos e a opção por ferramentas Internet, fica a sensação de que o BBS se pode construir juntando quatro serviços Internet: e-mail, ftp, http e news. Bastaria pois seleccionar um servidor de cada tipo, instalá-los numa máquina, e chamar ao conjunto BBS-RIA. Quanto à necessária visão integrada, consistente, homogénea e intuitiva que o utilizador necessita, ela seria deixada a cargo dos clientes WWW de uso genérico, multiprotocolares.

Sem pôr em causa o bom nível de integração que se consegue já hoje nos browsers "full-featured", os objectivos estariam longe de ser atingidos pois a integração existiria apenas no acesso aos serviços e não nos próprios serviços. Um dos muitos pontos onde seria notória a falta de integração é o da segurança, nomeadamente na autenticação e controlo de acessos. Pensando numa situação concreta, imagine-se um utilizador que pretende mudar da área de boletins (páginas HTML mantidas num servidor HTTP) para a área de ficheiros (mantidos num servidor FTP). Estando cada uma das áreas sujeita a um sistema próprio de segurança, o utilizador seria estranhamente confrontado com dois procedimentos diferentes de autenticação durante a mesma sessão de trabalho. Em resumo o BBS tem de ser mais do que a mera soma das partes que o constituam.

Isto permite-nos reflectir na integração de serviços, mas do lado do servidor. Ou seja, um sistema oferecendo serviços distintos como se oferecesse apenas um. O BBS-RIA pode ser visto como um exercício de integração deste tipo.

Na arquitectura adoptada, ilustrada na Figura 2, existe apenas um servidor que centraliza toda a comunicação com os clientes: um servidor HTTP. Este, no entanto, implementa apenas um parcela das funcionalidades necessárias sendo necessário acrescentar as restantes de forma a satisfazer todos os requisitos enumerados para o BBS. No sistema actualmente em funcionamento essas funcionalidades específicas foram colocadas num programa, designado módulo BBS-RIA, ligado ao servidor pelo interface CGI [7] (Common Gateway Interface).

Figura 2 - Arquitectura do servidor do BBS

Todo o processo decorre então da seguinte forma: O servidor HTTP atende um pedido proveniente de um dos clientes do BBS. De seguida executa via CGI o módulo BBS-RIA passando-lhe os dados do pedido. Este módulo executa todo o processamento do pedido utilizando para tal a sua base de dados própria e acedendo aos documentos existentes sejam eles boletins, mensagens ou ficheiros. De seguida o resultado é entregue ao servidor que se encarrega apenas de o fazer chegar ao originador do pedido.

Esta arquitectura baseada num servidor HTTP genérico complementado com um módulo CGI, embora tenha permitido chegar rapidamente a uma versão minimamente funcional, implica algumas desvantagens importantes:

Uma boa alternativa passa pela inclusão das funcionalidades do módulo BBS-RIA num servidor HTTP.

5. Funcionalidades do módulo BBS-RIA

O módulo BBS-RIA é o componente da arquitectura responsável por complementar o servidor HTTP executando o processamento específico do BBS. Mesmo algumas funções que aparentemente poderiam ser executadas pelo servidor como a autenticação, o controlo de acessos ou o registo de eventos estão a cargo deste módulo. Pretendeu-se desta forma dispor de funções perfeitamente adaptadas aos requisitos do BBS, realizadas sobre a sua própria base de dados e que permitam fornecer um visão integrada dos diversos serviços.

5.1 Autenticação

O BBS-RIA suporta já alguns mecanismos de segurança, estando outros apenas previstos para futuros desenvolvimentos. A autenticação e o controlo de acessos são dois aspectos fundamentais, incluídos desde o início nos requisitos gerais, e sem os quais muitos dos restantes requisitos apontados não fazem sentido. Confidencialidade e integridade são exemplos de mecanismos previstos mas ainda não incluídos no BBS-RIA.

A versão 1.0 do protocolo HTTP [8] contém um esquema de autenticação simples, baseado em "username/password" e muito semelhante aos esquemas usados pelo FTP e TELNET (sem adendas). Este esquema de autenticação é suportado por quase todos os clientes e servidores WWW e os desenvolvimentos actuais fazem prever que, a breve trecho, outros esquemas de autenticação mais fortes sejam igualmente incorporados e usados. O BBS-RIA tenderá a acompanhar esses desenvolvimentos, uma vez que o protocolo HTTP foi privilegiado na interacção cliente-servidor.

O uso deste esquema de autenticação básico procura ainda possibilitar que os clientes WWW de uso genérico sejam potenciais clientes do BBS-RIA, o que poderia ser inviabilizado por outras soluções.

A confirmação da identidade do utilizador (username) é feita por comparação da password fornecida com a informação existente sobre utilizadores na base de dados do BBS-RIA. Dado que o HTTP é um protocolo não orientado ao estado, a autenticação é feita por cada pedido/resposta.

5.2 Controlo de acessos

Com base na autenticação é possível concretizar mecanismos de controlo de acesso. A cada objecto do BBS-RIA, forum, área ou boletim, é associado uma lista de controlo de acessos, onde figuram nomes de utilizadores e respectivo nível de acesso (Nenhum, Leitura, Escrita, Total) que lhe é concedido. Cada tentativa de acesso a uma dado objecto é admitida ou recusada consultando essa lista.

A utilização de um esquema de controlo de acessos próprio do BBS visa por um lado dar aos gestores dos fora a possibilidade de realizar uma gestão integrada do mesmo e por outro suportar granularidades específicas do BBS como por exemplo o acesso a um forum em vez do acesso a páginas ou directorias.

5.3 Registo de eventos

Como complemento natural das duas funcionalidades anteriores surge o registo de eventos. Uma primeira componente desta funcionalidade corresponde ao habitual registo de log de um servidor HTTP mas com algumas funcionalidades acrescidas. Em particular existe a possibilidade de lidar com entidades como fora ou áreas e não apenas com páginas e dispõe-se igualmente do registo da identidade do requerente, o que permite ter o histórico de cada utilizador.

Uma outra componente desta funcionalidade é a actualização de diversos índices e outras variáveis na base de dados do BBS-RIA. É o caso, por exemplo, dos números das mensagens lidas por utilizador. Este tipo de registos permite que cada lista de mensagens seja acompanhada da indicação das que já foram lidas e das que são novas. Habitualmente este tipo de preocupações é da responsabilidade do cliente e não do servidor. Existem dois argumentos para que no BBS-RIA não seja assim. O primeiro tem a ver com a comunidade de utilizadores, que em muitos casos (por exemplo nas escolas) partilham o mesmo PC e o mesmo software, não sendo praticável ter configurações individuais. O segundo prende-se com a "mobilidade" do utilizador, que pode aceder umas vezes de uma plataforma e outras de outra, sem conseguir partilhar esse tipo de informação entre ambas.

A informação originada pelo registo de eventos permite assim, não só a obtenção de estatísticas, mas também a criação de um ambiente altamente personalizado.

5.4 Geração dinâmica de páginas

Uma das características mais importantes do BBS-RIA é a possibilidade de utilizar a informação existente na base de dados interna para criar um ambiente personalizado. Em muitos casos o processo de controlo não se limita a ir buscar uma página previamente construída e a enviá-la. Em vez disso é ele quem gera a própria página utilizando para o efeito as características do utilizador, a lista de fora em que se encontra inscrito, as suas preferências ou o seu historial. Este mecanismo permite por exemplo criar múltiplos interfaces para o BBS, gerar listas de mensagens não lidas pelo utilizador ou gerar páginas com uma descrição o mais completa possível dos ficheiros disponíveis numa determinada directoria.

5.5 Submissão de documentos

Um outro requisito que se coloca em diversas áreas é o da submissão de documentos sejam eles ficheiros, boletins ou mensagens com attachements. O processamento necessário inclui a recepção do documento, a sua colocação em local apropriado (tendo em conta o forum a que se destina e o tipo de documento) e a actualização de índices na base de dados.

O principal problema que se levantou foi o da transferência dos ficheiros da máquina cliente para o BBS. Nestes casos os clientes WWW de uso genérico actualmente disponíveis não podem ser usados pois não suportam esse tipo de operações. A insuficiência não é protocolar (recorde-se os métodos POST e PUT) . Quando muito a linguagem HTML deveria contemplar elementos que despoletassem nos clientes a indicação/selecção de ficheiros a transferir como é proposto em [9]. No entanto também nos servidores a tendência (pelo menos nos mais conhecidos) é para não suportar o método POST, a menos da utilização de CGI scripts para o efeito.

Por forma a ultrapassar esta limitação desenvolveu-se um pequeno cliente HTTP cuja finalidade é tão somente a de realizar essa transferência. No lado do servidor o módulo BBS-RIA recebe do servidor HTTP o pedido de POST com o respectivo ficheiro, verifica a identidade do utilizador e as respectivas permissões para efectuar a operação, e coloca o ficheiro na área pretendida (indicada no URL).

5.6 Gestão remota

Outro tipo de funcionalidades disponibilizadas pelo BBS-RIA é o da gestão remota dos fora e destina-se ao subconjunto dos utilizadores do BBS-RIA que tem um conjunto acrescido de funções de gestão a seu cargo. É o caso do gestor do BBS e dos coordenadores dos respectivos fora. Os coordenadores de cada forum podem admitir (ou propor a admissão) de novos utilizadores e definir as respectivas permissões de acesso às várias áreas e objectos mantidos no BBS. O gestor por sua vez, pode ainda criar e destruir fora.

Na grande maioria dos servidores de informação Internet, estas tarefas, ou outras semelhantes, só são possíveis de efectuar na máquina hospedeira do servidor. A gestão remota é sempre possível recorrendo ao acesso remoto por terminal (Telnet, por exemplo). No contexto do BBS-RIA e tendo em conta o tipo de utilizadores que se pretende alcançar bem como as particularidades dos sistemas utilizados optou-se antes por disponibilizar todas as tarefas de gestão descritas através de forms HTML elaboradas para o efeito, confiando no mecanismo de autenticação e controlo de acessos.

A aposta na gestão distribuída justifica-se ainda na perspectiva de que os coordenadores e o gestor do BBS são utilizadores com responsabilidades adicionais, mas que, tal como os restantes, pretendem o mesmo ambiente integrado, homogéneo e intuitivo.

6. Discussão da solução proposta

É notório, no BBS-RIA, o esforço de encapsulamento de quase todas as funcionalidades e serviços sobre HTTP. Esta solução pode parecer demasiado restritiva e desnecessária, tendo em conta que os clientes WWW são multiprotocolares.

Neste capítulo pretende-se fazer uma reflexão, serviço a serviço, sobre as principais opções tomadas, contrapondo as soluções alternativas.

6.1 Conferências

As conferências, integradas nos fora, são na sua essência, semelhantes aos grupos de news da Internet. O utilizador pode listar todas as mensagens, ordená-las de várias formas, fazer pesquisas por assunto, autor, etc., ler mensagens e submeter mensagens. Quase tudo funcionalidades oferecidas pelos leitores de news, e recentemente também por alguns browsers WWW.

A utilização de um servidor de news poderia ser uma solução a menos da necessidade de usar os mesmos mecanismos de autenticação e controlo de acessos nas três grandes áreas de cada forum. O protocolo NNTP [10] não foi concebido com demasiadas preocupações nestes dois aspectos, dado o tipo de utilização universal que se pretende do serviço de news na Internet.

Outro ponto desfavorável desta alternativa prende-se com a forma como as mensagens são apresentadas. Nesta fase inicial, pretende-se evitar que as mensagens surjam com cabeçalhos despropositados e inadequados. Este controlo da apresentação das mensagens não desrespeita o uso interno dos formatos RFC822 [11].

Embora a solução adoptada tenha sido reescrever um módulo de gestão de mensagens, acessível via HTTP, não está excluída a compatibilidade completa entre uma área de mensagens de um forum e um grupo de news normal. Para que essa interligação seja possível , será apenas necessário escrever uma entidade protocolar.

6.2 Área de Ficheiros

A área de ficheiros está disponível por HTTP. A navegação é a forma de acesso mais atractiva, e consegue-se recorrendo a geração dinâmica de páginas com a lista de ficheiros e uma descrição tão completa quanto necessário dos mesmos. A informação da base de dados do BBS permite ainda marcar os ficheiros já transferidos e as novidades. Para a submissão de ficheiros utilizam-se os mecanismos de submissão de documentos já discutidos.

Embora, pelos motivos já apontados, não esteja prevista a utilização por parte dos utilizadores de clientes FTP ou dessa funcionalidade nos Browsers, não está posta de parte a hipótese de incluir no servidor BBS-RIA um servidor FTP. Essa inclusão visaria sobretudo potenciar o uso de ferramentas como o mirror ou mesmo serviços como o Archie que poderiam ser especialmente relevantes nas interacções entre BBS

6.3 Boletins Informativos

Quanto aos boletins informativos, o facto de serem páginas HTML satisfaz imediatamente a maioria dos requisitos apontados pelos utilizadores: "disponibilizar informação temática multimédia, navegável em hipertexto com ligações às outras formas de suporte aos fora (conferências e boletins)".

Existe no entanto um requisito mais específico para o qual não existe uma resposta prática. Trata-se da edição de boletins e respectiva árvore de navegação, que são operações da responsabilidade do coordenador de cada forum. Tal como as operações de gestão já referidas, a manutenção da árvore de boletins informativos seria mais fácil se fosse efectuada localmente, isto é, na máquina de suporte ao BBS. Porém, pelos mesmos motivos apontados a favor de uma gestão distribuída, a edição da árvore de boletins deve ser possível remotamente.

A dificuldade está no conjunto de operações que o coordenador pode ter de fazer para colocar um novo boletim ou eliminar um antigo se quiser preservar a coerência de todos os "hiperlinks". Podem envolver a transferência de vários boletins para a máquina local, fazer as respectivas correcções e a transferência no sentido inverso.

No BBS-RIA, estão pensadas soluções que auxiliem esta tarefa, e que se resumem para já, à correcção automática de referências, ou seja, na substituição integral em toda a árvore de boletins de uma referência por outra.

6.4 Correio Electrónico

Um dos serviços BBS-RIA que, neste momento, está claramente "isolado" dos restantes é o serviço de correio electrónico inter-pessoal. A solução actual é suportada por um servidor SMTP [12] e um servidor POP [13], e os utilizadores foram convidados a usar clientes E-Mail normais.

Os clientes WWW genéricos suportam a submissão de mensagens (por SMTP), mas não suportam directamente o acesso a mailboxes remotas com protocolos do tipo POP ou IMAP [14]. Este é um dos pontos onde é necessário intervir para atingir a necessária integração.

A solução está já equacionada e passa pela inclusão de um gateway para estes servidores, numa primeira fase, e pela reescrita de um módulo especial de manipulação de mailboxes via HTTP numa segunda fase.

A solução alternativa seria conseguir a integração do lado do cliente através da introdução de uma nova entidade protocolar (IMAP e/ou POP) e da utilização da mesma informação de autenticação (username/password) em todos os tipos de acesso. Recorde-se no entanto que, no BBS-RIA, a aposta é a integração no servidor.

6.5 Outros serviços

O BBS-RIA não se esgota nas funcionalidades enumeradas. Existem alguns serviços adicionais que podem ser facilmente integrados. Um dos exemplos mais óbvios é o acesso a bases de dados externas, com os mais variados conteúdos (imagens, som e video). Estes acessos podem ser integrados recorrendo à elaboração de gateways específicos.

A arquitectura do BBS-RIA permite inclusivé pensar no alargamento de alguns fora à comunidade Internet em geral, nos mesmos moldes de coordenação ou sob a forma de fora não moderados para evitar sobrecarga de gestão. Por outro lado, o BBS-RIA também pode servir de porta de acesso à Internet para os seus utilizadores desde que se permita e estimule a inclusão de qualquer tipo de URLs, sem restrições.

Existem no entanto alguns serviços, apontados como necessários, mas de integração mais difícil no BBS. É o caso da comunicação interactiva (vulgo "Chat"). Dois utilizadores, que estejam a usar o BBS em simultâneo, podem desejar trocar impressões directamente e em tempo real. Uma das dificuldades iniciais, que deriva do facto do HTTP ser um protocolo não orientado ao estado, é saber em cada instante que utilizadores estão a usar o BBS. Será que se pode inferir algo a partir da hora do último pedido? Outro problema é como forçar a comunicação com um utilizador sem que ele tenha feito um pedido. Porque não usar a infraestrutura RDIS de suporte? Não será isso um "passo a trás" nos objectivos de integração? Embora este tipo de aplicações não esteja posto de lado, os esforços actuais da equipa de desenvolvimento passam apenas pelo discutir de soluções alternativas.

7. Utilização prática

O BBS RIA está actualmente em funcionamento experimental contando com 21 fora. Estão neste momento ligados aos DT&S cerca de 60 acessos básicos. No total estão ligados 80 terminais RIA. O número de utilizadores é superior dado que muitos destes terminais estão localizados em escolas sendo acedidos por mais do que um utilizador. Estão em fase de instalação 7 acessos a redes locais já existentes em escolas que irão permitir o acesso ao BBS de todos os computadores aí instalados. A entrada em funcionamento efectiva do BBS está agendada para Setembro, estando a decorrer neste momento a formação dos coordenadores dos fora e dos técnicos de apoio em cada uma das instituições participantes.

Pequena demonstração do BBS. (Apenas do acesso aos foruns e alguns boletins!).

8. Conclusões

Embora alguns dos requisitos funcionais identificados fossem à primeira vista possíveis de satisfazer com recurso a quatro grandes serviços Internet: e-mail, news, ftp e http, o BBS não resulta da simples junção de servidores. Tanto os coordenadores dos fora como os utilizadores têm necessidade de um ambiente integrado, homogéneo, consistente e intuitivo. Isto implica, por exemplo, a existência de um único processo de autenticação e de controlo de acessos para todos esses serviços.

A aposta no WWW (em particular no protocolo HTTP e na linguagem HTML) justifica-se plenamente, não só pelo uso de interfaces gráficos multimédia bastante atractivos, mas sobretudo pela certeza de se estar a utilizar um dos sistemas de informação em maior evolução na Internet, o que representa por si só um valor acrescentado importante em termos de formação.

A decisão por browsers WWW como interfaces do BBS deixou no entanto alguns problemas por resolver. Dadas as insuficiências ainda existentes nesses browsers enquanto interfaces universais não foi possível integrar funcionalidades como a submissão de documentos, o correio electrónico ou o acesso a serviços interactivos. Foi por isso necessário recorrer a soluções que não respeitam os princípios de integração propostos.

Este facto não retira no entanto validade à opção pelo WWW pois pensa-se que estas soluções sejam apenas provisórias sendo em breve possível encontrar soluções mais adequadas. Esta convicção resulta por um lado de se estar a lidar com uma tecnologia em rápida evolução, tanto ao nível dos protocolos como das ferramentas, e por outro de se tratar de problemas que não são específicos do BBS-RIA mas que se colocam igualmente em muitos outros serviços Internet. Antevê-se por isso que essa evolução vá facilitando a progressiva integração de todas as funcionalidades do BBS.

Quanto à colocação das funcionalidades do BBS num programa ligado a um servidor HTTP via CGI revelou-se uma opção boa para permitir um rápido arranque inicial mas complicada em termos de evolução futura. Uma solução mais escalável deverá passar pela integração dessas funcionalidades com as de um servidor HTTP resultando dai um servidor HTTP com funcionalidades de BBS ou se preferir um programa de BBS que atende pedidos via HTTP.

A RDIS, pela avaliação que neste momento é possível fazer, surge como uma boa solução para o acesso à Internet, em particular na utilização de serviços como o WWW. A sua utilização tem no entanto algumas particularidades que têm a ver com a sua natureza orientada à conexão e a taxação por tempo. Embora não exista no software BBS-RIA qualquer imposição de utilização da RDIS, estas particularidades foram tidas em conta de modo a conduzir a um bom aproveitamento desse ambiente de comunicação. Foi assim que surgiram funcionalidades como por exemplo modos de leitura de mensagens off-line..

Embora o WWW seja sobretudo visto como um caminho para o ciberespaço a sua utilização no ambiente mais restrito de uma dada comunidade permite antever novos serviços, baseados em ambientes de comunicação altamente personalizados e orientados a objectivos mais concretos.

9. Trabalho futuro

As principais áreas de desenvolvimento previstas são:


Nota

As seguintes instituições participaram na especificação dos requisitos e funcionalidades do BBS-RIA, e como coordenadoras de Fora neste BBS estão a participar activamente na sua operação, avaliação e refinamento que se vai desenrolar durante o ano de 1995:
Associação Comercial de Aveiro, EPCA-Escola Profissional de Comércio de Aveiro, Escola Magalhães de Lima - Aveiro, Escola José Estevão - Aveiro, Escola Secundária de Mangualde, Escola Secundária nº1 - Aveiro, Escola Aires Barbosa - Aveiro, TDS, Centro Tecnológico da Cerâmica e do Vidro, CUPC - Centro Universitário de Fé e Cultura, CCGN - Cooperativa Cultural da Gafanha da Nazaré, Ordem dos Médicos de Viseu, CFAE - Centro Formação da Associação de Escolas de Aveiro,Universidade Aveiro - DQUA, Universidade Aveiro - CIFOPUA, Universidade Aveiro - DTEUA, Universidade Aveiro - DETUA, Universidade Aveiro - DMATUA.


Referências

[1] CCITT, Blue Book, Fascicles III.7, III.8, III.9: Integrated Services Digital Network (ISDN),Recommendations I.110-I.605, ITU, 1989

[2] CET, Material didatico do curso Introdugco ` RDIS, 1994

[3] F. Carvalho, A. Marinheiro, A.Costa, R. Josi e L. Fonseca, Especificagco Funcional do BBS-RIA, Agosto 94

[4] F. Carvalho, A. Marinheiro, A.Costa, R. Josi e P. Correia, Especificagco Ticnica do BBS-RIA, Agosto 94

[5] W3C, The World Wide Web Initiative: The project, http://www.w3.org/

[6] T. Berners-Lee and D. Connolly. Hypertext Markup Language - 2.0, INTERNET-DRAFT, MIT/W3C, Maio 1995, work in progress from the HTML Working Group of the IETF

[7] W3C, Overview of CGI, http://www.w3.o rg/hypertext/WWW/CGI/Overview.html

[8] T. Berners-Lee, R. T. Fielding and H. Frystyk Nielsen. Hypertext Transfer Protocol -- HTTP/1.0, INTERNET-DRAFT, Margo 1995, work in progress from the HTTP Working Group of the IETF

[9] E. Nebel and L. Masinter. Form-based File Upload in HTML , INTERNET-DRAFT, Xerox Corporation, Abril 1995, work in progress from the HTML Working Group of the IETF

[10] Kantor, B.; Lapsley, P., RFC 977, Network News Transfer Protocol, 1986

[11] Crocker, D., RFC 822, Standard for the format of ARPA Internet text messages, 1982

[12] Postel, J., RFC 821, Simple Mail Transfer Protocol, 1982

[13] Myers, J.; Rose, M., RFC 1725, Post Office Protocol - Version 3, 1994

[14] Crispin, M., RFC 1730, INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4, 1994