1Um comentário

• Marcelo Moreno(usuário não autenticado)

  29 de Maio de 2008, 12:03

   

  Ola, Paulo

     Cada middleware estrangeiro teve suas peculiaridades de especificação e implantação.

     O MHP europeu era inicialmente uma especificação baseada no Java, procedural. Ganhou outros perfis para incluir aplicações baseadas no XHTML pensando principalmente no uso do canal de retorno para acesso a Internet. A partir daí o XHTML também poderia ser usado para a construção de aplicações interativas enviadas por difusão, restritas a navegação local.

     Com o ARIB japonês ocorreu o contrário, era inicialmente uma especificação baseada em XHTML, chamada BML, declarativa. Desde o início o BML considereva a necessidade de programação imperativa, mas por meio de scripts, Ecma. BML é, portanto, uma abordagem declarativa complementada por scripts. Posteriormente, para aderir ao GEM, o ARIB vem a incluir opcionalmente a máquina Java, procedural, com API compatível com o MHP. Porém, em termos práticos, apenas o BML é utilizado no Japão.

     Com o DASE e ACAP americanos a história se complicou porque lá os operadores de cabo são maioria e já adotavam uma solução GEM (OCAP), que pressionou a primeira especificação DASE. Mas foi o primeiro sistema que desde sua especificação considerava a existência de uma máquina de apresentação XHTML e uma máquina de execução Java. Com a pressão, e a proposta ACAP testada na Coréia e aderente ao GEM, o ATSC acabou por modificar o padrão de middleware retirando o DASE e introduzindo o ACAP-X declarativo e o ACAP-J como procedural.

      Aprendendo com os erros dos demais, o Brasil teve a oportunidade de propor um middleware especificado desde o início com uma máquina declarativa e uma procedural. A aderência ao GEM era tida como recomendável, por questões de compatibilidade com aplicações internacionais. Mas isso acabou por perder força dados os obscuros royalties da Via licensing para o GEM. Bem, de qualquer forma teremos um Ginga-J compatível ou funcionalmente equivalente ao GEM, acrescido das contribuições da UFPB com as novas APIs que melhoram muito o aspecto visual e interatividade das aplicações. No lado declarativo, somos os primeiros a adotar uma linguagem realmente focada no sincronismo de mídias, a NCL, por ser o sincronismo um problema presente na grande maioria das aplicações multimídia. Adicionamos ao Ginga-NCL a capacidade de scripting por meio da linguagem Lua, uma das linguagens interpretadas de melhor desempenho do mercado. Ainda assim, é possível trazer aplicações XHTML de fora para serem apresentadas pelo Ginga, pois XHTML é um tipo de mídia aceito pelo Ginga-NCL. Temos ainda a funcionalidade de edição ao vivo de aplicações NCL, sem precedentes em TV digital.

     Então eu não diria que estamos seguindo o mesmo caminho dos outros middlewares, mas que traçamos o nosso desviando dos erros deles. Projetamos desde o início um middleware com ambos ambientes procedural e declarativo, dos quais todas as possíveis redundâncias foram retiradas, resultando numa implementação leve. Além disso, a ponte de mão dupla entre Ginga-NCL e Ginga-J permite total integração entre os dois ambientes, o que não pode ser observado em tal grau em outros middlewares. Esses benefícios só puderam ser atingidos porque houve investimento em pesquisa e desenvolvimento na academia, apesar do curtíssimo tempo de projeto disponível.

  []s
  Moreno