NoVNC (link em inglês) é um cliente VNC, implementado usando HTML5 WebSockets, Canvas e Javascript. A InfoQ fez um pequena sessão P&R (Perguntas e Respostas) com Joel Martin sobre o noVNC e sua experiência em desenvolvimento de aplicações utilizando HTML5:
InfoQ: Joel, você gostaria de nos dar uma visão arquitetural do noVNC e como seus componentes se integram?
Joel: A arquitetura do noVNC é composta de 6 componentes principais:
- Núcleo de Implementação VNC/RFB: Este componente encapsula toda a inteligência do protocolo RFB e é a máquina principal que orquestra todo o resto.
- Abstração do Canvas: Esse componente fornece um abstração das API’s do Canvas do HTML5. Ele também tem a funcionalidade de detecção do Canvas para lidar com navegadores que não possuem a implementação completa do HTML5.
- Interface com usuário: Toda interação com o HTML DOM (exceto Canvas) está encapsulada aqui. Este componente renderiza os controles da página como o botão de conectar/desconectar, configurações, e o status das respostas. Um dos meus principais objetivos no desenho da implementação do noVNC é torná-lo fácil para ser embutido em sites já existentes, por isso esse componente é opcional.
- Utilidades: Este contém diversas rotinas genéricas e extensões utilizadas pelo noVNC incluindo: extensões para arrays Javascript para torná-los mais úteis como filas, gerenciamento de eventos entre navegadores, depuração/logging. Eu também irei incluir algumas bibliotecas Javascript de outras fontes para realizar codificação/decodificação e criptografia DES (para autenticação no noVNC)
- Compatilibilidade do WebSockets: a maioria do navegadores por aí não possuem suporte nativo para WebSockets, por isso eu incluí um emulador do Flash (flex) para esses navegadores. Eu extendi o projeto original com suporte a encriptação para WebSocktes.
- Proxy do WebSockets para TCP: O WebSockets por padrão não é uma implementação pura do socket TCP. Existe uma validação inicial parecida com a do HTTP para estabelecer a conexão e depois cada pacote enviado começa com um byte 0 (zero) e termina com um byte 255. Até que os servidores VNC implementem suporte para WebSockets (algo que eu gostaria de ver acontecendo) o proxy é necessário para realizar a tradução entre WebSockets e o socket padrão TCP. Eu implementei isso como um proxy genérico (em ambas Python e C) o que pode ser muito útil para outros desenvolvedores que estão trabalhando com WebSockets.
InfoQ: Quais foram seus principais desafios em desenvolver uma aplicação HTML5. Quais são as principais armadilhas que os desenvolvedores tem que estar atento?
Joel: O principais desafios tem sido os relacionados em lidar com os navegadores que não tem algumas funcionalidades do HTML5 ou funcionalidades do HTML5 limitadas, que funcionam de maneira errada ou estão quebradas. Por exemplo, enquanto o Chrome 5 e o Safari 5 possuem suporte nativo ao WebSockets, a versão corrente do Firefox e do Opera não. Algumas versões antigas desses navegadores não possuem a API mais recente do Canvas para manipulação de pixel (ou pior, ela existe mas está quebrada, que é o caso do Arora 0.5). Nenhuma versão do Internet Explorer possue suporte a WebSockets ou mesmo um suporte básico ao Canvas (o IE 9 Preview possue um suporte preliminar ao Canvas). Outro desafio é otimização e desempenho entre os diferentes navegadores. Cada navegador possui características diferentes de desempenho e isso ainda muda a cada diferente versão (e podem ser diferentes entre o mesmo navegador em diferentes sistemas operacionais). Essa é uma das MUITAS poucas áreas onde eu acho apropriado a detecção do navegador.
InfoQ: Quais as ferramentas você usou? Você achou que o poder das ferramentas atuais de desenvolvimento suficiente para construir aplicações HTML5? Que tipo de novas ferramentes você gostaria de ver?
Joel: Meu ambiente de desenvolvimento é bem pequeno. Eu uso Vim (com muitas extensões) no Linux para edição de código. Eu fiz uso pesado do Firebug no Firefox e as ferramentas do desenvolvedor embutidas no Chrome para depuração e perfilamento. Eu também fiz uso liberal do JSLint do Crockford para manter meu código Javascript sano. Eu gostaria que as ferramentas de perfilamento do Firebug e do Chrome oferecessem uma resposta mais granular ao invés ser no nível de função. Eu gostaria também que os perfiladores fornecessem mais sugestões em qual partes do código são as maiores contribuidoras para a coleta de lixo. O código do noVNC está agora otimizado no ponto em que a execução do coletor de lixo é um dos principais problemas de desempenho.
Uma nova ferramenta que eu gostaria de ver é um analisador de código (na mesma idéia do JSLint) que varreria um código Javascript e gerasse uma boa tabela de suporte entre navegadores. O resultado que eu gostaria seria uma lista de funcionalidades utilizadas no código no topo da tabela, e os maiores navegadores e suas versões na esquerda. Cada célula diria se a forma que o código está utilizando tal funcionalidade é suportada para tal navegador/versão. Isso eliminaria a necessidade de testar o código em tantos navegadores, mas isso certamente ajudaria durante o processo de desenvolvimento para saber se você está no caminho certo ou não. Idealmente o varredor deve detectar se o Javascript está lidando corretamente com detecção/solução daquela funcionalidade entre os navegadores.
InfoQ: Quais foram as principais limitações das especificações correntes e implementações que você teve que superar?
Joel: Felizmente, esta é uma área ondes as especificações estão muito boas.
O protocolo RFB (VNC) é bem documentado aqui: http://tigervnc.org/cgi-bin/rfbproto.
Este site fornece uma ótima referência para Javascript (incluindo quais versões dos navegadores suportam cada funcionalidade): http://www.hunlock.com/.
O melhor site que encontrei que documenta qual navegador suporta qual funcionalidade (cobrindo HTML5 e muito mais) é http://caniuse.com/. O site http://quirksmode.org é inestimável pelos detalhes finos de qual navegador suporta quais APIs e como lidar com tais limitações. A maior limitação de um navegador que eu tive que superar foi a falta de um suporte nativo a WebSockets. Esse é um padrão recente e ainda está em mudanças, mas está sendo rapidamente adotado. Está agora no webkit por isso Chrome 5 e o Safari 5 tem então o iPhone provavelmente terá isso em breve. Isso provalmente virá no Firefox 4. Cedo ou tarde o Opera também implementará. A grande questão é se o IE 9 irá suportar.
Como eu disse acima. Eu uso um emulador do WebSockets do Flash para atender navegadores sem suporte nativo. Extender, corrigir e lidar com bugs no código do Flash (ActionScript) tem sido uma grande tarefa . Interligar Javascript e Flash tem sido a maior dor de cabeça. A Adobe fornece o FABridge (que o emulador utiliza) mas essa interligação é lenta, desajeitada e ruim de depurar.
Enquanto eu soube pelas notícias que o IE 9 iria ter completo (e rápido) suporte ao Canvas, eu ainda gostaria de superar a falta de qualquer suporte nativo ao Canvas nas antigas versões do IE desde que elas são tão prevalentes. As duas opções que estou considerando são ExplorerCanvas e FxCanvas. ExplorerCanvas é uma biblioteca Javascript que cria uma API Canvas em cima do suporte VML do IE e o FxCanvas é uma implementação em Flash do Canvas. Entretanto, ambas opções tem grandes problemas. O ExplorerCanvas não tem suporte a manipulação de pixel (devido ao VML ser vetorial ao invés de ser por bitmap), e o FxCanvas fornece somente uma API parecida com a do Canvas e tem alguns, não triviais, problemas de processamento assíncrono. Infelizmente, o motor Javascript no IE 6, 7 e 8 são tão lentos comparados com outros navegadores disponíveis que fazem emulação do Canvas pode muito bem se provar inviável e eu provavelmente vou terminar sugerindo as pessoas que usem o Chrome.
InfoQ: Quais são seus futuros planos para o projeto noVNC?
Joel: A coisa que atualmente está mais me animando é trabalhar com alguns desenvolvedores do QEMU/KVM (incluindo um estudante do Google Sumer of Code) para desenhar um novo codificador VNC que é mais otimizado para renderização em navegadores. Esse novo codificador VNC/RFB transfere as informações da imagem no formato PNG. Em adição a boa compressão e baixa perda de dados (se comparada a com codificação simples), as informações de imagem PNG são facilmente renderizadas em um navegador com pequeno esforço de decodificação (diferente da codificação simples).
O requerimento do proxy do WebSockets para TCP é uma barreira para uso amplo do noVNC. Eu gostaria de ver suporte a WebSockets serem adicionados a servidores VNC. Eu pessoalmente estou focando na libvncserver (que a qual é usada na construção de vários diferentes servidores VNC) e a QEMU/KVM. Mas eu adoraria ajudar e encorajar outros desenvolvedores de servidores VNC a adicionarem suporte. Adicionando suporte a WebSockets em outros clientes VNC também seria útil porque o protocolo WebSockets é desenhado para facilmente ser suportado e “proxiado” pelos servidores Web (daí a compatiblidade com a validação inicial de uma conexão HTTP). Isso pode ajudar com um dos problemas históricos do VNC que é lidar com firewalls. Uma das razões que eu nomeei o projeto como “noVNC” foi porque eu gostaria de ver implementações de outros protocolos de “rede virtuais de computadores” tais como RDP, NX e o protocol Spice da Red Hat.
Se e quando o iPhone adicionar suporte nativo ao WebSocket (obviamente a opção do Flash está fora de questão), então eu adoraria ter o noVNC rodando no iPhone. Uma funcionalidade que eu gostaria de adicionar que seria provavelmente muito úti. E Google, se você estiver ouvindo, um telefone Android de graça seria uma grande inspiração para ter o noVNC funcionando no Android. :-)
Uma abordagem similar foi feita pelo projeto Guacamole que o qual também é cliente HTML5 para o VNC, que usa um proxy do lado do servidor escrito em Java. A versão corrente é tida com a mais responsiva quanto um cliente VNC nativo e funciona em qualquer navegador que suporte a marcação ‘canvas’ do HTML5.
Você pode encontrar maiores informações sobre HTML5 e Aplicações Ricas de Internet, bem aqui na InfoQ!