Kepler Mobile
Uma plataforma de código aberto para dispositivos móveis
English | Português

Histórico

O projeto Kepler Mobile foi proposto pela primeira vez em 2004 como uma forma de criar uma plataforma móvel viável para dispositivos móveis baseada em Linguagem Lua.

A FINEP e o SEBRAE patrocinaram o projeto, que contou desde o início com o apoio da PUC e da Fábrica Digital.

Foi determinado que o projeto seria iniciado com um estudo das plataformas mais promissoras no cenário da computação móvel, além de uma comparação das ferramentas de desenvolvimento disponíveis para cada uma delas.

Após a seleção da plataforma e do ferramental, a pŕoxima etapa foi a seleção da versão do Lua para a migração. A versão selecionada então foi a 5.1.4 -- a mais recente até então. Desde o início foi constatado que o pacote de código-fonte do interpretador Lua original não estava preparado para ser compilado imediatamente na nova plataforma. Desse modo, um novo procedimento de compilação precisou ser desenvolvido.

Desde o início, foi utilizado como referência o trabalho de migração desenvolvido por um membro da comunidade Kepler, Ian McIntosh, que havia iniciado um trabalho de portar o interpretador Lua para a palaforma Windows Mobile. O objetivo do trabalho de McIntosh, porém, era diferente do nosso. Enquanto ele pretendia criar uma aplicação de console nós objetivamos o desenvolvimento de aplicações web. Contudo, a referência se mostrou extremamente útil, iluminando áreas problemáticas na migração que de outra forma teriam que ser descobertas através de extensa pesquisa prévia ou pelo método de tentativa e erro.

O maior obstáculo à migração do interpretador Lua para o ambiente Windows Mobile se dá na figura da biblioteca de tempo de execução da linguagem C. O ambiente Windows Mobile não possui um suporte adequado às funcionalidades padrão POSIX da IEEE e isto tem impactos direto em diversas partes da API de módulos como LuaFileSystem e LuaSockets. A solução deste problema mostrou-se mais sutil do que esperávamos.

Durante a primeira fase do processo de migração para a plataforma, utilizamos uma implementação de diversas funções do padrão POSIX implementada na forma de uma biblioteca de vínculo dinâmico pelos criadores do pacote CeGCC. Com essa bibliteca pretendíamos encurtar bastante o desenvolvimento das funcionalidades mais complexas -- a saber, o acesso ao sistema de arquivos e às conexões de rede, ou sockets -- uma vez que, dispondo de uma camada que simularia uma interface padronizada, poderíamos fazer uso de soluções já comprovadas em outras plataformas mais comuns.

Entretanto, o pacote de compatibilidade do CeGCC não apresentou o nível de maturidade exigido para migração, apresentando diversas instabilidades e deixando de atender alguns requisitos importantes. A resposta da comunidade que mantinha essa biblitoeca também não foi satisfatória, assim como o fato de algumas respostas a dúvidas que publicamos em seu fórum oficial terem ficado várias semanas sem resposta. Este conjunto de problemas nos convenceu de que esse caminho teria de ser abandonado.

Após um estudo mais detalhado das características do problema, a opção escolhida foi o desenvolvimento com as ferramentas de compilação MinGW-ARM, desenvolvidas pela equipe do CeGCC, e que faziam a compilação para o ambiente, mas mantendo todas as suas limitações. O efeito dessa decisão foi o de termos que implementar nós mesmos as lacunas de funcionalidade que eventualmente se fizessem necessárias para realizar cada uma das partes esperadas das APIs dos módulos. Apesar de mais trabalhosa, esta opção se mostrou viável.

Migração do Interpretador Lua

O maior desafio à migração do Interpretador Lua consistiu na adaptação do mesmo ao tipo de codificação de caracteres suportado pelo sistema operacional Windows Mobile. Escrito em linguagem C de padrão ANSI, o código fonte do interpretador Lua se viu em muitos casos utilizando construções padrão dessa linguagem, como cadeias de caracteres terminadas em um caracter NULL (NULL-terminated strings). Tal construção não era totalmente amigável ou ambiente novo, uma vez que todos os caracteres do novo ambiente eram codificados em UTF-16, no qual cada caracter ocupa dois bytes de memória. Com o auxílio de membros da comunidade Lua, foi possível realizar uma série de intervenções no interpretador que permitiram que seus mecanismos internos não sofressem alterações oriundas dessas particularidades que fossem danosas à execução das aplicações pretendidas.

Infelizmente, não foi possível realizar todos os testes padronizados fornecidos pelos criadores de Lua para teste da plataforma, uma vez que algumas funcionalidades tiveram que ser deixadas de lado na migração do interpretador, por limitações do ambiente alvo -- como os testes de estresse de memória e disco, e as funcionalidades de execução de comandos no shell. Algumas dessas lacunas serao abordadas à posteriori em melhorias incrementais ao trabalho; nenhuma delas, porém, constituiu obstáculo à execução dos testes que fizemos.

Por fim, uma das questões que representavam maior preocupação dizia respeito à carga dinâmica de módulos. Esse problema foi abordado inicialmente, mas contornado durante a migração do módulo LuaFileSystem, que exigiu uma solução diferente, como veremos em seguida.

Migração do módulo LuaFileSystem

Um dos módulos com a maior quantidade de desafios técnicos, o LuaFileSystem depende pesadamente do sistema de arquivos -- uma das maiores diferenças entre o Windows Mobile e os sistemas onde a plataforma Kepler roda originalmente. Dentre as diversas dificuldades enfrentadas durante a migração deste módulo podemos destacar como uma das principais a ausência do conceito de 'diretório corrente' -- que dificulta a implementação de funções como chdir (mudança de diretório) e abertura de arquivos. A solução adotada foi a emulação de um diretório corrente em memória, e a subsequente utilização deste diretório em todas as operações de abertura de arquivos, execução de scripts ou operações de diretório. A questão se mostrou mais complexa do que pareceu à primeira vista, pois não só as funções utilizadas pelo LuaFileSystem precisaram ser reescritas, como também diversas funções de outros módulos e do próprio interpretador Lua deveriam ser alteradas para que usassem nossa biblioteca alternativa de acesso ao sistema de arquivos.

Outra dificuldade importante foi a dificuldade em converter os formatos utilizados pelo sistemas operacional para descrever características dos arquivos em sua API. Essas estruturas puderam ser aproveitadas do pacote de compatibilidade fornecido pelo ferramental, porém muitos ajustes e definições de símbolos específicos foram exigidos até que todos os testes pudessem ser satisfeitos.

Por fim, a necessidade de se alterar todos os acessos a disco para que utilizassem um único mecanismo central de representação do diretório corrente exigiu que os módulos binários, que normalmente seriam acessados através de carga de bibliotecas de vínculo dinâmico (DLLs) fossem carregados juntamente com o interpretador de uma única vez. Essa mudança de arquitetura permitiu que pudéssemos garantir a estabilidade e atomicidade da carga inicial dos módulos, uma vez que a carga em si das DLLs era uma operação sensível a contexto de diretório.

Migração do módulo LuaSockets

O módulo LuaSockets, apesar de representar um dos maiores riscos tecnológicos previstos no projeto, não apresentou tantos problemas quanto esperado em sua migração para o Windows Mobile. O maior desafio para sua migração, uma vez concluída a seleção de quais funcionalidades trazer para a nova plataforma, consistiu em um problema comum à arquitetura dos módulos binários -- a ordem de carregamento.

Muitos módulos Lua formados por partes escritas em Lua e partes escritas em linguagem C utilizam um projeto tal que exige a carga inicial através do código Lua e uma posterior adição das funções presentes em suas bibliotecas de vínculo dinâmico. Com a decisão de carregar todas as DLLs juntamente com o executável essa lógica de carga deixou de ser válida -- causando diferenças no comportamento de módulos como o LuaSocket e o luasocket.mime.

Com diversos ajustes, foi possível garantir o correto funcionamento do módulo para todas as funções pretendidas, e a execução satisfatória dos testes de unidade.

Executando do Xavante no dispositivo

O primeiro teste do servidor web Xavante foi feito com o módulo Copas, capaz de criar um servidor TCP/IP cuja implementação está escrita em Lua. Em nossos testes, fizemos um simples servidor de eco -- um servidor que retorna via socket exatamente o que recebeu -- ouvindo em uma porta do dispositivo, e acessado a partir de uma estação desktop normal. Uma vez que esse teste foi bem-sucedido, pudemos prosseguir com os demais pré-requisitos para a execução do Xavante.

O módulo Rings foi o único que apresentou um maior grau de dificuldade, pois era escrito em linguagem C. Além disso, uma vez que a função principal do Rings é criar novos Estados Lua (LuaStates) -- instâncias do interpretador Lua totalmente independentes umas das outras -- o processo de carga prévia de todas as bibliotecas binárias juntamente com o executável não era estendido para os novos estados. Foi necessário refatorar a implementação de toda a estrutura de carga inicial para permitir a acomodação de um modo de injetar esses módulos em um novo estado Lua.

Como esperávamos, uma vez resolvidas as dependências binárias, a adaptação do código-fonte do servidor Xavante -- totalmente escrito em Lua -- foi muito simples. Na primeira semana de abri de 2009 a primeira versão totalmente funcional do servidor Xavante estava sendo executada em um dispositivo Windows Mobile.

Migrando outros módulos

Uma vez que o Xavante funcionava a contento, restava preparar o terreno para a execução do teste definitivo da plataforma Kepler no novo ambiente. Esse teste consistia em demonstrar nossa habilidade de migrar uma aplicação e suas dependências -- binárias ou não -- para a plataforma alvo, e testá-la no dispositivo. A aplicação escolhida foi a wiki Sputnik, base do desenvolvimento das bibliotecas de abstração de dados e sincronismo que vinham sendo executadas em paralelo pela equipe e se basearam na arquitetura extensível da wiki Sputnik. Uma vez concluídas as tarefas foi muito mais fácil garantir que elas funcionariam no dispositivo sem problemas dado que todas as suas dependências já haviam sido testadas.

Alguns outros módulos (necessários para a execução da wiki Sputnik) foram testados na nova plataforma, a saber:

Valid XHTML 1.0!

$Id: index.html,v 1.19 2009/02/22 13:40:42 jasonsantos Exp $