Pessoal, desde o ano passado que estou estudando Java e TV Digital. Porém comecei a ver o GINGA-NCL e também sobre a Linguagem LUA. Bom, como várias pessoas estão falando que o GINGA-J ainda não foi liberado, tem diversos desenvolvedores JAVA esperando para que seja liberado para que possam começar a desenvolver.
Bom PArticipei do II encontro de Software Livre de Pernambuco onde assistit a palestra de Eduardo Santos, do Ministério do Planejamento/DF. A palestra foi excelente, muito boa mesmo. Porém ao questioná-lo sobre o Ginga-J e que eu estava esperando que fosse liberado pra eu poder começar a programar, ele me informou que eu poderia está perdendo tempo, pois posso inicar o desenvolvimento com o java e dentro do NCL chamar o arquivo .jar. hehehehehe depois disso me senti confuso, até porque ele me disse que não precisaria espera pra começar a desenvolver.
Gostaria que o MArcelo Moreno ou alguem aqui da comunidade, explicasse pra gente desenvolverdor JAVA. o que realmente é e será o GINA-J e se temos condições de inicar nossos desenvolvimento usando o JAva dentro dos arquivos NCL.
Quero inicar meus estudo e preciso de orientação.
Muito Obrigado.
Autor: Emerson Alencar
3131 comentários
Qualquer dessas alternativas será complementada pelo conjunto de APIs brasileiras (amarela e vermelha) criadas pelos pesquisadores da UFPB. Porque existem essas alternativas? A primeira promove compatibilidade do Ginga-J com o GEM, e assim as aplicações MHP já desenvolvidas lá fora e que usam apenas o subconjunto de APIs GEM funcionariam no SBTVD. Problema: Royalties. Consulte a Via licensing para maiores detalhes sobre os royalties relacionados ao MHP. A segunda é uma especificação em andamento pela Sun e que passará por aprovação e implementação em código-aberto e livre de royalties pelos desenvolvedores de middleware participantes do Fórum do SBTVD. Problema: incompatibilidade com aplicações interativas européias. A escolha caberá ao Fórum do SBTVD. Eles colocarão na balança uma possível renegociação dos royalties com a Via licensing, contra a nova especificação da Sun. Acredito que a Sun termine essa especificação ainda no 1o. semestre deste ano, portanto essa decisão sairá em breve. Quero desenvolver aplicações Java para TV, agora! O que faço? Tente se basear ao máximo na API JavaTV. Se necessitar algo por fora, tente usar o próprio AWT. Se ainda for insatisfatório, use as APIs do MHP/GEM, porém saiba que um dia poderá ser necessária uma tradução para a nova especificação do Ginga-J, ou não. Para fazer seus testes, nossos membros têm usado o XleTView. Que tipo de suporte a aplicações Java as ferramentas hoje disponíveis na Comunidade Ginga possuem? Exatamente por não termos um Ginga-J definido, o suporte a Java disponível até o momento nas ferramentas relacionadas ao Ginga-NCL é ainda precário. Apenas o Ginga-NCL Emulator v.1.1.0 (também embutido no Composer v. 2.2.1) provê algum suporte, porém limitado a alguns eventos de controle de Xlets JavaTV, apenas. O objetivo principal é simplesmente demonstrar como será a comunicação entre a máquina de apresentação Ginga-NCL e a máquina de execução Ginga-J. Se você quer realmente ir mais a fundo na programação de Xlets, siga a dica da pergunta anterior. Quais opções de desenvolvimento de aplicações interativas o Ginga nos dará? A arquitetura do Ginga leva em conta que o produtor de conteúdo interativo pode ter ou não especialização em programação, e que suas aplicações podem ter requisitos funcionais os mais diversos possíveis. Por isso, há os dois ambientes para a execução de aplicações: Ginga-NCL (declarativo) e Ginga-J (procedural ou imperativo). Ginga-NCL é uma máquina de apresentação de documentos declarativos descritos em NCL, uma linguagem criada na PUC-Rio para definir em alto nível os relacionamentos espaço-temporais entre as diferentes mídias que compõem uma aplicação multimídia, como é o caso de grande parte das aplicações para TV (Leia o tutorial NCL!). É uma linguagem para a especificação do sincronismo entre mídias, sendo que cada ação de interatividade do usuário também é tratado como caso de sincronismo. Por ser uma linguagem declarativa voltada ao sincronismo, certas tarefas, principalmente as que envolvem algum tipo de computação, não podem ser escritas em NCL. Por isso, um documento NCL pode ser estendido por scripts em linguagem Lua, chamados NCLua, que são tratados como mais um caso de mídia por NCL (Leia o tutorial NCLua!). Da mesma forma, Xlets também podem ser acionados a partir de documentos NCL, quando então são chamados NCLets. Como dito anteriormente, pela indefinição do Ginga-J, o suporte a NCLets nas ferramentas da nossa Comunidade ainda é precário, mas já ilustra como deve ser o funcionamento (Leia o How-to!). Ginga-J é uma máquina de execução de aplicações Java que usam extensões da linguagem mais apropriadas ao hardware e ambiente de TV. A principal extensão usada mundialmente é a API JavaTV, que define as aplicações como Xlets, com um ciclo de vida bem definido. A indefinição sobre o Ginga-J recai exatamente sobre as extensões proporcionadas pelas APIs de terceiros. De qualquer forma, além das APIs compatíveis (GEM) ou funcionalmente equivalentes (Sun) aos middlewares internacionais, o Ginga-J possui APIs mais avançadas, denominadas Amarela e Vermelha (Leia a Norma!). As ferramentas para testes de aplicações Ginga-J serão disponibilizadas pela UFPB como software livre logo que a definição (e possível reimplementação) das APIs for definida pelo Forum do SBTVD. Há uma API para fazer a ponte entre Xlets e documentos NCL, o que representa o caminho de volta da técnica híbrida descrita no parágrafo anterior. Assim, com o Ginga é possível construir: aplicações declarativas puras (NCL); aplicações procedurais puras (Java); e aplicações híbridas (NCL + Lua; NCL + Java; Java + NCL). Espero ter ajudado a todos. Esta resposta será incorporada em breve ao conteúdo da Comunidade. Portanto, quem quiser acrescentar informações importantes que não abordei aqui, sejam bem-vindos. []s
Moreno
gingadf.blogspot.com/
Moreno
gingadf.blogspot.com/
Moreno
Carlos
Ginga: atraso na adoção ainda se deve ao risco de royalties
25/07/2008, 15h29 Uma fonte que faz parte do Fórum do Sistema Brasileiro de TV Digital diz que ainda não está resolvida a questão do Ginga, o middleware proposto para viabilizar a interatividade no padrão brasileiro. Vale lembrar, o Fórum do SBTVD chegou à conclusão que o GEM, parte integrante do Ginga que garante a interoperabilidade com os middlewares usados nos padrões estrangeiros, não apresenta garantias de que realmente seja livre de patentes estrangeiras. Em outras palavras, é possível que, após a base de equipamentos consolidada, apareça um detentor de uma patente cobrando royalties pela tecnologia embarcada nos equipamentos existentes e futuros. O risco jurídico faz com que os fabricantes de equipamentos de TV evite adotar o middleware. E, enquanto isso acontece, a TV digital brasileira segue com capacidade limitada de interatividade. Além disso, cresce a base de televisores e set-tops que nunca terão compatibilidade com aplicações interativas.
Conforme anunciado na última NAB, que aconteceu em abril, em Las Vegas, o Fórum do SBTVD e a Sun trabalhavam no desenvolvimento de algo semelhante baseado na linguagem de programação Java, usada também no desenvolvimento do GEM. A expectativa era que a versão final do middleware brasileiro estivesse pronta em maio ou junho deste ano.
Chegou-se a uma versão, mas que ainda não convenceu totalmente o Fórum de que é realmente livre de royalties. "A Sun propôs assumir os custos caso apareça alguém cobrando pela tecnologia", diz a fonte. Mas pondera: "ela vai pagar pela tecnologia empregada na base instalada de equipamentos. Mas quem vai pagar daquele momento em diante?". Neste caso, a indústria teria que aceitar o preço imposto pelo possível detentor de tecnologia usada no padrão. Substituir a tecnologia, por outro lado, deixaria um legado de equipamentos incompatíveis. Fernando Lauterjung - TELA VIVA News Mais queria saber como vai fica o caso do ginga-NCL... até quando iremos esperar para que PELO MENOS tenhamos o ginga-ncl nos set-up-box?? Enquanto isso, a base de usuarios que nao contem ginga está aumentando... futuramente, isso pode se torna uma bola de neve...
Moreno
Contudo, a interface Java oferece recursos poderosos para aplicações avançadas que se preocupem com os recursos da máquina. Assim podemos examinar meta-informações da programação, variáveis de serviço do set-top-box e assim por diante. Coisas simplesmente impossíveis em NCL (me corrijam se estiver errado). Creio que o importante seja entender bem os nichos, vantagens e desvantagens de cada método em cada situação. Quanto ao Composer só uma opnião. Estamos no começo dos tempos e o Composer é uma grande iniciativa, pois mesmo que se diga que é fácil aprender ncl/xml, muitas pessoas (como produtores de publicidade, por exemplo) poderiam já ter muita dificuldade com isso (nesses casos Java seria impossível mesmo).
No entanto o Composer ainda deverá crescer e melhorar. Eu acho que há um problema meio grave, e que é um problema de conceito.
Quanto eu quero fazer um menuzinho com umas seis opções, a visão estrutural (a mais simples e didática) torna-se um verdadeiro inferninho cheio de setinhas... não sei pode haver alguma mudança de paradigma na visão estrutural ou as vezes uma pequena alteração...
Desculpem por ficar divagando sobre o Composer neste tópico
=] Até mais Leonardo Leite
www.openginga.org Abraço a todos e sucesso, Marcos Henke
b4dtv.blogspot.com