22 comentários

• Marcos Vinícius Henke Arnoldo(usuário não autenticado)

  17 de Junho de 2008, 0:38

   

  Olá Ronaldo,

  pelo que eu tenho conversado, lido, acompanhado, a Sun não vai cobrar nada.

  A API JavaTV é FREE. O que é proprietário são as bibliotecas HAVi e algumas outras que compõem o GEM.

  A Sun inclusive ficou encarregada de realizar a especificação de uma biblioteca livre de licenças e royalties como alternativa a essas bibliotecas, então, ao meu ver, a alternativa 2 não deve ocorrer.

  Voce mesmo pode criar componentes e disponibilizar, desde que use puramente a API JavaTV e estenda os controles AWT.

  Quanto a sua questão 1, o modelo de licenciamento dos controles proprietários do GEM é diferente do que vemos por aí com componentes comerciais pra Delphi, Asp.Net, Java, que pagamos a licença por desenvolvedor e os clientes não pagam royalties.

  Quanto à sua questão 3, eu também tive essa dúvida quando iniciei meus estudos em TV Digital. Pesquisei e decobri que existir, existe. Você talvez até tenha em sua casa Sky TV, Net, ou outra TV por assinatura, digital, que possui aplicativos interativos rodando. Se vc não tiver, certamente um amigo ou parente seu tem.

  Mas ninguém sabe o que roda dentro. Que middleware? Que bibliotecas? Como funciona o canal de retorno do pay-per-view? Ninguém sabe, ou pelo menos, não divulgam.

  O mesmo ocorre em diversos outros sistemas no mundo inteiro, no show business a concorrência é muito grande, tudo fechado a sete chaves. Tente conseguir informações da Microsoft TV. Você vai descobrir que existe, mas só é disponibilizado para emissoras de TV e grandes produtoras.

  Isso é o que eu tenho acompanhado, talvez o pessoal mais experiente possa dar informações melhores.

   

  Abraço e espero ter ajudado,

  Marcos Henke
  b4dt​v.bl​ogsp​ot.c​om

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

  17 de Junho de 2008, 1:10

   

  Ola, Ronaldo.

     Sim, podemos dizer que o parto é doloroso. E já dura 4 anos... Mas não veja a situação como de toda ruim...

     O adiamento da norma do Ginga-J se deve ao questionamento sobre os royalties cobrados pelos proprietários da harmonização GEM, derivada do middleware europeu, ao qual o Ginga-J inicial procurou se aderir por motivos de compatibilidade. Ainda bem que tivemos esse questionamento e ainda bem, também, que apareceu a alternativa de desenvolvimento de um padrão funcionalmente equivalente, em parceria com a Sun. Cabe ao Fórum do SBTVD decidir se o Ginga-J continua como uma especificação aderente ao GEM ou aderente ao novo padrão com a Sun. Sugiro que todos leiam (ou releiam) a nota publicada pela Sun:

     www.​sun.​com/​abou​tsun​/pr/​2008​-03/​sunf​lash​.200​8030​4.2.​xml

     Respondendo suas perguntas:

     1) A filosofia do Ginga é não repassar qualquer custo no uso das especificações e linguagens aos desenvolvedores de middleware ou de aplicações. Portanto, NÃO, os custos de royalties não devem ser cobertos por desenvolvedores. Ginga-NCL foi concebido considerando o desenvolvimento livre como pilar. E, de novo, ainda bem que os royalties obscuros do GEM foram identificados no caso do Ginga-J.

     2) A Sun não vai dar preço. O desenvolvimento da nova proposta é baseado em código aberto entre os membros do Fórum do SBTVD. O uso das APIs do novo candidato a Ginga-J também não acarreta no pagamento de royalties, como é de praxe por parte da Sun. Afinal, você paga para usar o java.lang.*?

     3) Você vai encontrar diversas propostas de APIs para TV ou multimídia em geral, porém não se esqueça que temos normas já aprovadas, que regem o SBTVD, e que dizem que o Ginga é formado por uma máquina de apresentação NCL (com Lua) e uma máquina de execução Java.

      Ginga sai ou não sai? Para quem quer desenvolver aplicações interativas para TV, é melhor considerar que já saiu, ou partirá atrasado na exploração dessa nova mídia. NCL está aí. E mesmo em Java, inicie com Ginga-J/GEM, pois já vale o esforço, uma vez que, no máximo, sua aplicação deverá ser adaptada à potencial nova API que possui as mesmas funcionalidades.

  []s
  Moreno