Bom dia a todos.
Ontem foi finalizado o review da nova JSR 357, padronizando assim no java uma forma de comunicação com as redes sociais, que cada dia mais cresce no mercado corporativo.
http://jcp.org/en/jsr/detail?id=357
No meu ver otima noticia.
att.
Thiago Rolemberg
Parece interessante, mas cada rede social tem suas peculiaridades, além de que todas já possuem APIs em java para acessá-las. Será que precisamos de um foco bem nessa parte? Não sei dizer.
Eu acho que uma API destas iria nivelar por baixo, da mesma forma que o J2ME, que mais atrapalha do que ajuda … (ok, me preparando para as pedradas de algum adorador do J2ME)
Existem diferenças muito grandes entre redes sociais, se a API cobrir apenas o que é comum sera inútil, se for extensível, o código vai ficar tão complexo que vai ser mais fácil escrever do zero …
Claro que podem existir pontos interessantes, como permitir a utilização de qualquer rede social para se autenticar na aplicação, mas já existem bibliotecas para isto, e acho que uma JSR seria perda de tempo.
Os dados disponíveis sobre contatos são tão diferentes em cada uma delas que uma API única seria ou restrita demais ou genérica a ponto de não ser tão útil …
Mas claro, isto é só a minha opinião 
(sim, faz muito tempo que não apareço por aqui )
Olá
Não entendi qual a vantagem. É para ser uma alternativa chapa branca ao Spring Social (que nem vejo muita necessidade)?
Agora você voltou muito ao passado. Quem aqui se lembra para que serve isto?
Abraços
Luca Bastos
Concordo com o Paulo Silveira, todas redes já possuem uma API em java, umas boas outras ruins, mas funcionam.
Precisamos de outros tipos de melhorias…
Observe que a JSR 357 acabou de ser proposta: nesse momento ela passa pelo processo de votação no JCP, para ver se deve continuar ou não no processo. Ela ainda esta pelo menos 1 talvez 2 anos distante de chegar a uma versão da especificação.
É interessante que o Twitter está apoiando essa JSR, junto com a ReHat e a Oracle. Em geral, a maior dificuldade de se conseguir que um padrão “pegue” é trazer os grandes players da área. A presença do Twitter traz um peso gigantesco.
Com a crescente discussão sobre privacidade e controle dos seus próprios dados, uma forma de acesso mais geral a várias redes sociais (possibilitando por exemplo que seus dados pessoais seja migrados de uma para outra, ou replicados) torna essa discussão muito interessante do ponto de vista do usuário final.
Existem inclusive diversos projetos que fazem um pouco disso, o que favorece a razão da padronização. E quem disse que APIs genéricas precisam ser absurdamente complexas? Temos vários exemplos de APIs que “escondem” os detalhes (muitas vezes bem complexos) de bancos de dados, serviços de mensagens, e até mesmo sistemas operacionais inteiros, e que trazem vantagens concretas na sua aplicação. A arquitetura Java é inteira baseada nessa separação de API padrão + implementações específicas + extensões exclusivas, que promovem a padronização, e ajudam a evitar o “menor denominador comum”.
Por outro lado, existe uma discussão de que talvez seja muito cedo para se tentar criar uma especificação dessas, que talvez fosse melhor aguardar mais um tempo, até que esse espaço das redes sociais se consolide um pouco mais.
E você, o que você acha? Dentro de mais ou menos uma semana, o SouJava vai ter que dar o seu voto no comitê executivo do JCP, aceitando ou rejeitando essa proposta de API. Esse é um bom momento para se realizar essa discussão, a sua opinião tem tudo para decidir para onde vai nosso voto.
[]s,
Bruno.
O fato de existirem várias APIs Java para as diversas redes sociais é na verdade uma boa razão para se propor a padronização.
Padronização só funciona quando existem diversas implementações existentes, tentando resolver mais ou menos a mesma coisa (nesse caso, cada uma tenta acessar uma rede social diferente). Se não houvessem várias APIs, vários projetos, não faria sentido se falar em padronização.
Só assim se torna possível criar uma API padrão (“especificação”, “interfaces”), que seria implementada pelas várias APIs específicas (“drivers”, “providers”).
A questão não é se existem outros problemas a serem resolvidos (cada um trabalha no que acha importante, nesse caso, o Twitter por exemplo acha importante trabalhar nisso). A questão é se essa é uma necessidade para aplicações Java, se para o desenvolvedor Java que precisa integrar suas aplicações com redes sociais isso vai ajudar em alguma coisa.
[]s,
Bruno.
Pra mim, spec pra isso é perda de tempo. Perda de tempo do JCP que tem tanta coisa mais importante pra resolver antes de pensar em novas specs (JSR310?).
E os cenários de uso são meio duvidosos… o que exatamente ganha o desenvolvedor ao ter uma padronização pra algo tão pequeno e pontual como acesso a redes sociais. Já somos bem servidos com frameworks como Spring Social.
Se começarmos a padronizar qualquer JARzinho bobo por aí, vamos ter que criar spec pra gráficos (JFreeChart), relatórios (iReports?) etc. [aliás, todos esses casos são mais complexos e mais usados que APIs de redes sociais…]
Enfim, me pareceu totalmente fora do propósito do JCP essa spec.
Acho que seria um esforço sem muito retorno. Ela está mais para a JSR de JDO do que pra JPA. A JPA surgiu de uma necessidade, já havia vários frameworks querendo mapear bancos de dados relacionais. A JDO nasceu top-down.
Cada rede social tem objetivos bem diferentes. Bancos de dados relacionais tem objetivos bem parecidos. Vai acabar sendo uma API super genérica como o JDO, deixando detalhes de fora.
Posso estar pensando besteira, mas se a ideia é padronizar, por que apenas redes sociais? Por que não colocar no mesmo “saco” (API) tudo que se refere a autenticação e autorização? Não seria o caso de rever a especificação do JAAS?
–
Rei
Eu também dispensável uma JSR para isso.
Sou a favor da proposta da API.
[quote=bruno souza]O fato de existirem várias APIs Java para as diversas redes sociais é na verdade uma boa razão para se propor a padronização.
Padronização só funciona quando existem diversas implementações existentes, tentando resolver mais ou menos a mesma coisa (nesse caso, cada uma tenta acessar uma rede social diferente). Se não houvessem várias APIs, vários projetos, não faria sentido se falar em padronização…
[/quote]
É o poderoso java impondo a padronização nos players do mercado. Concordo que essa JSR ditaria um caminho para todas as redes, assim ao invés de termos VÁRIAS apis funcionando, cada qual do jeu jeito, teríamos uma parão. Sou a favor da API.
(ou até que as redes sociais deixem de existir, assim como foi com as salas de bate-papo, icq e outras febres)
Achei esquisito, mas se dizer que resolve… :?
Para mim tb…mas ainda é cedo para afirmar isso…
Eu acho que, do ponto de vista do desenvolvedor toda especificação é boa…
Eu vejo que é mais uma opção alem do SpringSource…
Por isso, sou sempre a favor!!!
Especificação sempre acima do “proprietarismo”…
Eu entendo que não.
Na verdade vc usaria uma estrategia de JAAS usando alguma implementação do JSR 357.
Os provedores de containers poderiam facilmente acrescentar + essa estrategia dentro das muitas opções existentes…
Bem…
porque disse que acho uma boa noticia:
O que mais cresce no mercado corporativo ultimamente é a utilização de redes sociais, toda vez que temos que desenvolver algo neste aspecto usamos varios jar’s para isso, no meu ver a padronização vem para ajudar, melhorar o que ja temos hoje no mercado.
Também concordo que a JCR tem outros assuntos para resolver, mas hoje trabalho em alguns projetos que usam redes sociais e como acha api, uma para cada rede o codigo acaba ficando horrivel desnecessariamente.
Agora senhores essa é minha opnião, entre diversas que estão sendo dadas aqui.
Eu sou a favor da API.
att.
Rolemberg
Acho realmente que tem muito uso essas APIs de comunicação com twitter e facebook, mas acho que sera frustrante tentar encaixar uma interface única para elas. Elas trabalham de maneira muito diferente, e aí acaba ficando algo meio JDO: tenta mapear tudo, ao mesmo tempo não foca em nada. Em outras palavras, por exemplo, acaba uma API que não consegue fazer tais coisas com facebook (já que é um recurso único dessa plataforma), ai voce precisará utilizar uma API direta.
Sei que bancos de dados relacionais possuem suas diferenças, mas o objetifo final é comum. nas redes sociais isso não ocorre.
[quote=Paulo Silveira]Acho realmente que tem muito uso essas APIs de comunicação com twitter e facebook, mas acho que sera frustrante tentar encaixar uma interface única para elas. Elas trabalham de maneira muito diferente, e aí acaba ficando algo meio JDO: tenta mapear tudo, ao mesmo tempo não foca em nada. Em outras palavras, por exemplo, acaba uma API que não consegue fazer tais coisas com facebook (já que é um recurso único dessa plataforma), ai voce precisará utilizar uma API direta.
Sei que bancos de dados relacionais possuem suas diferenças, mas o objetifo final é comum. nas redes sociais isso não ocorre.[/quote]
Eu tb acho que elaborar uma especificação pode acabar nesse caminho…mas não seria responsabilidade dos lideres da JSR viabilizar oq vai entrar como padrão e o que vai ser extensão proprietária?
A conclusão desse estudo poderia fechar a JSR…
[quote=FernandoFranzini]mas não seria responsabilidade dos lideres da JSR viabilizar oq vai entrar como padrão e o que vai ser extensão proprietária?
[/quote]
Sim, com certeza. Mas parece que quase tudo viraria extensão proprietária! :). Aquela api de data mining acho que teve fim parecido, creio que a versão 2.0 tenha sido abandonada por causa disso. Eu fiquei surpreso quando JDO conseguiu chegar no 2.0.