O grupo no qual você está postando é um grupo da Usenet. As mensagens postadas neste grupo farão com que o seu e-mail fique visível para qualquer pessoa na Internet
Mais q as diferenças, me chamaram atençao as similaridades (ver debate abaixo).
A Google ta percebendo q n dá mais p ficar desenvolvendo aplicacaozinha em browserzinho tosquinho: é preciso uma plataforma de aplicacoes baseada em componentes.
E no nivel mais fundamental, o Sneer e o Chrome sao bem isso: um container de aplicacoes baseadas em componentes.
Um nivel acima, ja comecamos a divergir: o Chrome é voltado a aplicacoes CLIENT que escravizam os usuarios a SERVERS, de preferencia, o próprio Google; ao passo q o Sneer é voltado a aplicacoes PEER-TO-PEER, q libertam os usuarios da dependencia dos servers.
Vc acha q o Google ganha um tostao furado de do trafego EMule q existe? Torrent? Skype? A ultima coisa na vida q o Google quer facilitar sao aplicacoes P2P. Por causa disso, o Chrome nao ameaça o espaço do Sneer.
Mercadologicamente eles tem a vantagem de serem backward-compatible com as aplicacoes web. Essa é também a desvantagem tecnologica deles, como vemos a seguir.
Vamos ao debate:
1) What do you think about browser-based development?
Concordo com o que vc escreveu, também não gosto do modelo de desenvolvimento de serviços que é imposto, acho muito complicado e nada divertido
Para mim é muito melhor escrever aplicações pequenas com funcionalidade especifica do que me preocupar sempre com várias situações que me chateiam porém, não entendo, como mudar isso?
Como fazer mais pessoas criarem seus bricks se elas querem so criar web2.0 - 3.0 e afins, criar sites e ficarem ricos( RoR, DJango, Flex, AJAX, DataBase, JPA e mais siglas etc...) onde trabalho todo mundo sonha em fazer um site usando estes esquemas, mas ninquem quer fazer OO, patterns etc, ser soberado para que? todos querem aderir ao modelo. como sair da matrix?
Como escrever e publicar programas soberanos hoje? mesmo fora do sneer? que usa? se todo mundo quer serviços na forma google de ser.
E quanto aos usuários que estão presos ao mundo WEB(universo google), como fazer eles instalarem uma aplicação(sneer) e usar serviços soberanos?
Como ser soberano se 99% das pessoas não quer sair da zona de conforto. e acho que eu estou nesse mundo dos 99%.
Ainda se a VM java fosse menor. a instalação mais rápida.
tentei desenvolver um e-mail marketing e tentar distribuir via web(applet). demora muito. varios jars pesados. os caras que desenvolvem não pensam em ser leves. um swingx tem 2.5mb isso é um absurdo. só aplicação desktop mesmo.
tentei separar só o que eu precisava, sem chance dependencia full entre pacotes.
se fizer um brick para snner como fica a sustentabilidade do negócio?
Se não fui claro posso explicar melhor, mas gostaria de respostas.
> Mais q as diferenças, me chamaram atençao as similaridades (ver debate abaixo).
> A Google ta percebendo q n dá mais p ficar desenvolvendo
> aplicacaozinha em browserzinho tosquinho: é preciso uma plataforma de
> aplicacoes baseada em componentes.
> E no nivel mais fundamental, o Sneer e o Chrome sao bem isso: um
> container de aplicacoes baseadas em componentes.
> Um nivel acima, ja comecamos a divergir: o Chrome é voltado a
> aplicacoes CLIENT que escravizam os usuarios a SERVERS, de
> preferencia, o próprio Google; ao passo q o Sneer é voltado a
> aplicacoes PEER-TO-PEER, q libertam os usuarios da dependencia dos
> servers.
> Vc acha q o Google ganha um tostao furado de do trafego EMule q
> existe? Torrent? Skype? A ultima coisa na vida q o Google quer
> facilitar sao aplicacoes P2P. Por causa disso, o Chrome nao ameaça o
> espaço do Sneer.
> Mercadologicamente eles tem a vantagem de serem backward-compatible
> com as aplicacoes web. Essa é também a desvantagem tecnologica deles,
> como vemos a seguir.
> Vamos ao debate:
> 1) What do you think about browser-based development?
Vou te contar um segredo de como vai ser o futuro. Soh n conta p
ninguem, beleza?
> RoR, DJango, Flex,
> AJAX, DataBase, JPA e mais siglas etc...
Eh normal as pessoas quererem usar as siglas da moda. Afinal, sao
coisas que supostamente trazem mais produtividade ao desenvolvimento
web. Sao como construir mais um "puxadinho" na tecnologia de
desenvolvimento web.
Mas chega uma hora que o mega-cortico de puxadinhos de papelao ja nao
presta mais. O Chrome propoe forrar de concreto os puxadinhos. O Sneer
ja chega passando o trator.
Vejo duas grandes vertentes possiveis pro futuro:
1) A humanidade vai evoluir para uma especie de "colmeia Borg" com
alguem no centro, comandando tudo.
2) A humanidade vai evoluir para uma rede de partes autonomas,
soberanas, se comunicando e decidindo cooperar qdo virem ganho na
cooperacao.
Historicamente tem sido sempre uma mistura dessas duas coisas, entao
vejo muito espaco, por muito tempo, tanto para o jeito Borg/Google
quanto para o jeito soberano de ser.
Entao, a menos de um futuro completamente Borg, eh >>INEVITAVEL<< q a
coisa evolua assim:
1) Vamos desenvolver a versao inicial do Sneer, uma plataforma para o
desenvolvimento facil de componentes e aplicacoes seguros, robustos e
distribuidos.
2) Vamos divulgar para nossos amigos.
3) Gradualmente vamos sensibilizar uma comunidade de programadores
visionarios, sysadmins inovadores e militantes da liberdade (turma do
software livre).
4) Outras plataformas podem surgir independentemente ou inspiradas no
Sneer. Embora por definicao sejam, podem nem ser chamadas de
"soberanas". O Sneer pode ateh cair em ostracismo.
5) Vamos viver uma era romantica, ingenua, gostosa, desenvolvendo
aplicacoes para nosso proprio uso, compartilhando com os amigos, mais
ou menos como eram os micreiros nos anos 80 ou usuarios de linux nos
anos 90.
6) A medida que as aplicacoes desenvolvidas pela comunidade inicial se
tornarem cada vez mais interessantes, cada vez mais usuarios
(independente de serem borgs ou soberanos) vao usa-las. Cada vez mais
desenvolvedores vao querer desenvolver para a plataforma, num ciclo
virtuoso, ate q isso se torne um inferno comercial e padrao de fato.
7) Vamos contar para nossos netos que fizemos parte da revolucao.
Portanto, nao precisa ficar muito ansioso. Curta os momentos de 1 a 5
enquanto puder. :)
> Meu inglês não e bom então nem vou tentar usa-lo.
> Concordo com o que vc escreveu, também não gosto do modelo de
> desenvolvimento de serviços que é imposto, acho muito complicado e nada
> divertido
> Para mim é muito melhor escrever aplicações pequenas com funcionalidade
> especifica do que me preocupar sempre com várias situações que me
> chateiam porém, não entendo, como mudar isso?
> Como fazer mais pessoas criarem seus bricks se elas querem so criar
> web2.0 - 3.0 e afins, criar sites e ficarem ricos( RoR, DJango, Flex,
> AJAX, DataBase, JPA e mais siglas etc...) onde trabalho todo mundo sonha
> em fazer um site usando estes esquemas, mas ninquem quer fazer OO,
> patterns etc, ser soberado para que? todos querem aderir ao modelo. como
> sair da matrix?
> Como escrever e publicar programas soberanos hoje? mesmo fora do sneer?
> que usa? se todo mundo quer serviços na forma google de ser.
> E quanto aos usuários que estão presos ao mundo WEB(universo google),
> como fazer eles instalarem uma aplicação(sneer) e usar serviços soberanos?
> Como ser soberano se 99% das pessoas não quer sair da zona de conforto.
> e acho que eu estou nesse mundo dos 99%.
> Ainda se a VM java fosse menor. a instalação mais rápida.
> tentei desenvolver um e-mail marketing e tentar distribuir via
> web(applet). demora muito. varios jars pesados. os caras que desenvolvem
> não pensam em ser leves. um swingx tem 2.5mb isso é um absurdo. só
> aplicação desktop mesmo.
> tentei separar só o que eu precisava, sem chance dependencia full entre
> pacotes.
> se fizer um brick para snner como fica a sustentabilidade do negócio?
> Se não fui claro posso explicar melhor, mas gostaria de respostas.
>> Mais q as diferenças, me chamaram atençao as similaridades (ver debate abaixo).
>> A Google ta percebendo q n dá mais p ficar desenvolvendo
>> aplicacaozinha em browserzinho tosquinho: é preciso uma plataforma de
>> aplicacoes baseada em componentes.
>> E no nivel mais fundamental, o Sneer e o Chrome sao bem isso: um
>> container de aplicacoes baseadas em componentes.
>> Um nivel acima, ja comecamos a divergir: o Chrome é voltado a
>> aplicacoes CLIENT que escravizam os usuarios a SERVERS, de
>> preferencia, o próprio Google; ao passo q o Sneer é voltado a
>> aplicacoes PEER-TO-PEER, q libertam os usuarios da dependencia dos
>> servers.
>> Vc acha q o Google ganha um tostao furado de do trafego EMule q
>> existe? Torrent? Skype? A ultima coisa na vida q o Google quer
>> facilitar sao aplicacoes P2P. Por causa disso, o Chrome nao ameaça o
>> espaço do Sneer.
>> Mercadologicamente eles tem a vantagem de serem backward-compatible
>> com as aplicacoes web. Essa é também a desvantagem tecnologica deles,
>> como vemos a seguir.
>> Vamos ao debate:
>> 1) What do you think about browser-based development?
2008/10/1 Klaus Wuestefeld <klauswuestef...@gmail.com>
> A Google ta percebendo q n dá mais p ficar desenvolvendo > aplicacaozinha em browserzinho tosquinho: é preciso uma plataforma de > aplicacoes baseada em componentes.
O Mozilla foi o real pioneiro nesse front, com o XUL, que permite criar funcionalidades bastante avançadas sem nenhum código nativo, só com Javascript, HTML etc. É por isso que os plugins do Firefox são tão populares, pois vc não corre risco de pegar um vírus ou bug de buffer overflow, o que não pode ser dito de plugins nativos como os ActiveX do MSIE. E o Firefox 3.1 (com TraceMonkey) terá desempenho similar ao Chrome para Javascript, a grande vantagem do Gears/Chrome será a disponibilização de componentes importantes como database relacional, etc.
> 2) How do you keep applications from messing each other up?
> Sneer: Using Bricks. Bricks communicate only through Java interfaces. > The container can intercept and control the communication between > them.
The problem is Java's large per-process loading time and footprint. I've just read a very interesting paper from IBM about a "Cloneable VM", they extend the Isolates API (JSR-121) to support a cloneMe() method that will clone a running JVM process - just like the well-known Unix fork() call, but with extras like being able to reconstruct threads, file descriptors and other OS resources in the forked JVM. They implement this in WebSphere so, once a first WebSphere JVM is running, new instances can be cloned in a couple seconds (while a standard "boot" of WebSphere often takes minutes, it's a bitch of bloatware). And the cloned JVMs can share a lot of RAM footprint thanks to old-school copy-on-write memory management. So you can have strong OS process isolation for security, resource management and other purposes. It's a very interesting trend, if this technology becomes mainstream it will benefit platforms like Sneer.
The Isolates API itself was never implemented in production JVMs, now there's a follow-up, the JSR-284: Resource Consumption Management API, that may succeed to evolve this idea and have it implemented in popular JVMs. It's worth notice that Grzegorz Czajkowski, the spec lead and major researcher of Isolates (author of most important papers and implementations) is now working at Google. IIRC, Android's Dalvik VM does have some kind of isolation (multiple apps / single process) capabilities. Dalvik's source code will be open by "Q4 2008", that's RSN, it should be interesting to check.
On Wed, Oct 1, 2008 at 2:18 PM, Osvaldo Doederlein <opin...@gmail.com> wrote:
> Opa,
> 2008/10/1 Klaus Wuestefeld <klauswuestef...@gmail.com>
>> A Google ta percebendo q n dá mais p ficar desenvolvendo
>> aplicacaozinha em browserzinho tosquinho: é preciso uma plataforma de
>> aplicacoes baseada em componentes.
> O Mozilla foi o real pioneiro nesse front, com o XUL, que permite criar
> funcionalidades bastante avançadas sem nenhum código nativo, só com
> Javascript, HTML etc. É por isso que os plugins do Firefox são tão
> populares, pois vc não corre risco de pegar um vírus ou bug de buffer
> overflow, o que não pode ser dito de plugins nativos como os ActiveX do
> MSIE. E o Firefox 3.1 (com TraceMonkey) terá desempenho similar ao Chrome
> para Javascript, a grande vantagem do Gears/Chrome será a disponibilização
> de componentes importantes como database relacional, etc.
>> 2) How do you keep applications from messing each other up?
>> Sneer: Using Bricks. Bricks communicate only through Java interfaces.
>> The container can intercept and control the communication between
>> them.
> The problem is Java's large per-process loading time and footprint. I've
> just read a very interesting paper from IBM about a "Cloneable VM", they
> extend the Isolates API (JSR-121) to support a cloneMe() method that will
> clone a running JVM process - just like the well-known Unix fork() call, but
> with extras like being able to reconstruct threads, file descriptors and
> other OS resources in the forked JVM. They implement this in WebSphere so,
> once a first WebSphere JVM is running, new instances can be cloned in a
> couple seconds (while a standard "boot" of WebSphere often takes minutes,
> it's a bitch of bloatware). And the cloned JVMs can share a lot of RAM
> footprint thanks to old-school copy-on-write memory management. So you can
> have strong OS process isolation for security, resource management and other
> purposes. It's a very interesting trend, if this technology becomes
> mainstream it will benefit platforms like Sneer.
> The Isolates API itself was never implemented in production JVMs, now
> there's a follow-up, the JSR-284: Resource Consumption Management API, that
> may succeed to evolve this idea and have it implemented in popular JVMs.
> It's worth notice that Grzegorz Czajkowski, the spec lead and major
> researcher of Isolates (author of most important papers and implementations)
> is now working at Google. IIRC, Android's Dalvik VM does have some kind of
> isolation (multiple apps / single process) capabilities. Dalvik's source
> code will be open by "Q4 2008", that's RSN, it should be interesting to
> check.
"One reason you should not use web applications to do your computing is that you lose control," he said. "It's just as bad as using a proprietary program. Do your own computing on your own computer with your copy of a freedom-respecting program. If you use a proprietary program or somebody else's web server, you're defenceless. You're putty in the hands of whoever developed that software."
E o que é pior eles disponibilizam como persistência banco de dados, (complexibilidade animal), sendo que persistir objetos seria bem melhor.
Tentei uma vez fazer algo com o xulrunner, tive que desistir pois o código ficava horrivel( sql dentro do JavaScript ) fora outras coisas bizarras.
Com a versão 6u10 da jre podemos ter uma aplicação java disponível em jnlp e applet, bastando apenas um drag and drop, isso é animal. mas volto ao problema do tamanho da vm e da dependência de pacotes.
> "One reason you should not use web applications to do your computing
> is that you lose control," he said. "It's just as bad as using a
> proprietary program. Do your own computing on your own computer with
> your copy of a freedom-respecting program. If you use a proprietary
> program or somebody else's web server, you're defenceless. You're
> putty in the hands of whoever developed that software."
> Com a versão 6u10 da jre podemos ter uma aplicação java disponível em > jnlp e applet, bastando apenas um drag and drop, isso é animal. mas > volto ao problema do tamanho da vm e da dependência de pacotes.
Isso. Ou vc faz baixo-nivel em C/C++ e perde portabilidade; ou obriga o usuario a subir uma VM a cada nova aplicacao. Fora isso, as aplicacoes/componentes nao tem como se comunicar sem ser por sockets locais.
O modelo atual de isolamento de aplicacoes/componentes do Java nao resolveu este problema. Por isso a necessidade da JSR 121 - Application Isolation, atualmente no mesmo estagio q o Sneer: "Vaporware".
O Sneer resolve justamente este problema: cada novo componente/aplicacao roda isoladinho, mas dentro da mesma VM.
O OSGi tbem tem o mesmo objetivo, mas eh mais complexo e burocratico q eu gostaria. Isso eh inevitavel em qq processo de design-by-comittee.
|Com a versão 6u10 da jre podemos ter uma aplicação java disponível em
|jnlp e applet, bastando apenas um drag and drop, isso é animal
Quando falo em jnlp/applet, quero perguntar, o sneer poderia ser
distribuido desta forma?
Sendo que os bricks e arquivos usados por eles estariam na máquina do
usuário.
Com a versão 6u10 da jre podemos ter uma aplicação java disponível em
jnlp e applet, bastando apenas um drag and drop, isso é animal. mas
volto ao problema do tamanho da vm e da dependência de pacotes.
Isso. Ou vc faz baixo-nivel em C/C++ e perde portabilidade; ou obriga
o usuario a subir uma VM a cada nova aplicacao. Fora isso, as
aplicacoes/componentes nao tem como se comunicar sem ser por sockets
locais.
O modelo atual de isolamento de aplicacoes/componentes do Java nao
resolveu este problema. Por isso a necessidade da JSR 121 -
Application Isolation, atualmente no mesmo estagio q o Sneer:
"Vaporware".
O Sneer resolve justamente este problema: cada novo
componente/aplicacao roda isoladinho, mas dentro da mesma VM.
O OSGi tbem tem o mesmo objetivo, mas eh mais complexo e burocratico q
eu gostaria. Isso eh inevitavel em qq processo de design-by-comittee.
Flw
