 |
gildot |
 |
| |
| | Falemos de sistemas de componentes em Linux | | |  | Contribuído por scorpio em 25-04-03 12:52
do departamento development-corner | |  | |  | | |  fhc escreve "Hoje em dia uma aplicação é de tal maneira complexa que a modularização é essencial. Depois da função e do objecto vieram os componentes, que são objectos com capacidade de introspecção (ou refexivos). Sejam Java Beans, Bonobo ou KParts, existem hoje sistemas de componentes que fazem sentido usar em Linux. Já programei Java Beans (não há quase nada que saber) e componentes Bonobo. Creio que Bonobo é desnecessariamente difícil uma vez que métodos tenham de ser adicionados, e uma nova interface CORBA derivada. Adicionar propriedades no objecto é, no entanto, simples. Mas fazer a depuração de um objecto Bonobo fica entre um grave desconforto e um sério ordálio. Java Beans tem o problema eterno (Java, apenas, só, e nada mais). Quanto a KParts, confesso pouco saber, mas creio que os seus defensores elogiam-lhe a capacidade e os detractores a quase impossibilidade de sair de C++ para os programar e utilizar. Lançaria à discussão o seguinte: será Bonobo uma tecnologia simples, ou um novo OpenGL dos gráficos (que todos odeiam, mas todos programam nisso). Seria bom ter regras de um único sistema de componentes para KDE e GNOME? Sei que excluo Offix, UNO e outros protosistemas: tenho que me cingir ao que pode vingar no futuro imediato. Francisco Colaço " | | | | | | < And Now, For Something Completely Different... | Linux Vx Windows > | | gildot Login | | | Referências | | |
| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Só se forem os que nunca conheceram os pipelines de visualização que haviam antes...
|
| | | | Depois da função e do objecto vieram os componentes, que são objectos com capacidade de introspecção (ou refexivos).
ja existem ha dezenas de anos linguagens com capacidades "introspectivas": smalltalk, lisp, you name it... O "mundo empresarial" decididamente nao acompanha o "mundo academico". Nos ultimos 10 anos, tudo o que foi reinventado, tem servido como pseudo-inovaçao. A tecnologia de ha 20 anos esta' por fim a generalizar-se. Mudem-lhe o nome... chamem-lhe inovaçao. Mas nao tenham duvidas que essas tecnologias ja sao usadas de forma superior e sustentada, com provas dadas e usadas comercialmente/profissionalmente por alguns com visao alargada.
|
| | | | | | Repara que nunca pus datas no surgimento da reflexão, que vem sendo gradual desde os anos 80. Pessoalmente uso python e gosto muito de introspecção. Mas confesso que Bonobo só é fácil de usar de linguagens como Java ou Python. Tenho componentes feitos em C e são uma miséria quando é necessário mantê-los ou acrescentar-lhes funcionalidade. Francisco Colaço
|
| | | J2EE. (Pontos:2, Informativo) |
| | | Java Beans tem o problema eterno (Java, apenas, só, e nada mais). Nao vejo porque seja um problema -- Java e' multi-plataforma, correndo em tudo desde PC's a Mac's e Telemoveis. Alem disso tem um API extremamente completo, e e' uma linguagem consistente. Quanto ao bonobo, a pergunta e' de que forma e' que e' um sistema comprovado na industria. Quantas aplicacoes comerciais foram desenvolvidas com o Bonobo ?
"I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | | | O lock-in-ware que são as JVM's tornam o Java num problema. Se não forem utilizadas classes gráficas (AWT, Swing, etc) há alternativas que começam a ser algo viáveis, mas na generalidade não. De resto, ele estava a falar de Beans, e não Enterprise Beans, que são outra coisa.
KParts, bonobo, e outras alternativas livres são tentativas (umas melhores outras piores) que têm surgido, mas não necessáriamente vingado. O mesmo se pode dizer de várias tecnologias semelhantes todas vindas de Redmond.
Quanto a aplicações comerciais (pois presumo que já saibas que software livre também pode ser -- e é -- utilizado comercialmente) em GNU/Linux utilizando bonobo ou KParts... que benchmark é esse? Numa qualquer instalação comercial de GNU/Linux tenho milhares de aplicações. Algumas utilizam bonobo, outras KParts, a maior parte apenas shared libraries, uma minoria utiliza static linking e nenhuma em Java Beans. Isto não é estatística, são factos. Do meu ponto de vista, bonobo e KParts estão muito mais comprovados na indústira :)
A verdadeira pergunta é: compontentes é uma bala de prata? A resposta é não. Como em todas as tecnologias de programação, há que ter 2 dedos de testa e pensar sériamente se isso vale a pena.
|
| | | | | O lock-in-ware que são as JVM's tornam o Java num problema. Mais uma -- porque e' que uma JVM e' "lock-in-ware" ? E' tao uma "lock-in-ware" como o interpretador de Perl, ou o uso da STL do C++. Faz parte da linguagem, mais nada -- ja' se passou do tempo em que todas as linguagens teem que ser compilaveis. Quanto a aplicações comerciais (pois presumo que já saibas que software livre também pode ser -- e é -- utilizado comercialmente) em GNU/Linux utilizando bonobo ou KParts... que benchmark é esse? Imagina que vais desenvolver um projecto chave para a tua organizacao (empresa ou nao, nao interessa) -- vais desenvolver os sistemas usando uma linguagem/tecnologia para a utilizacao da qual nao tens garantias de encontrar quem tenha os conhecimentos para a desenvolver ? Quantas pessoas conheces que teem bons skills de Bonobo ? Quantas empresas/terceiros podem desenvolver/manter algo escrito numa linguagem/API/sistema de componentes que raramente e' utilizado na industria ? Isto nao conta para ti ? Numa qualquer instalação comercial de GNU/Linux tenho milhares de aplicações. Algumas utilizam bonobo, outras KParts, a maior parte apenas shared libraries, uma minoria utiliza static linking e nenhuma em Java Beans. Isto não é estatística, são factos. Do meu ponto de vista, bonobo e KParts estão muito mais comprovados na indústira :) Olha, o teu ponto de vista esta' errado... you are the weakest link, goodbye..
"I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | Mais uma -- porque e' que uma JVM e' "lock-in-ware" ? E' tao uma "lock-in-ware" como o interpretador de Perl, ou o uso da STL do C++. Faz parte da linguagem, mais nada -- ja' se passou do tempo em que todas as linguagens teem que ser compilaveis.
Evidentemente nunca leste as licenças para comparar :)
Quanto ao que conta para mim, é a utilização das tecnologias certas nos locais certos; para mim, uma tecnologia não livre nunca é uma tecnologia certa. Pode ser boa/útil a curto prazo, mas a médio/longo estás tramado. O argumento do pragmatismo é muito bonito, até se começar a pensar a uma escala temporal maior. E nesse momento, quem pensa mais longe é mais pragmático. É a diferença de vistas curtas / vistas longas.O primeiro ponto que eu foco é: componentes serão mesmo necessários?.
Bem, tu podes achar o meu ponto de vista como errado, e ser um elo mais fraco. Tudo bem. Deve ser por isso que não tenho um emprego a desenvolver componentes. Deve ser por isso que tenho mais de 4 Gb de software instalado no meu computador (a maioria normalmente não uso, mas sabe-se lá...). Não me parece um ponto de vista assim tão irreal. Deve ser por ser baseado em factos...
|
| | | | | Quanto ao que conta para mim, é a utilização das tecnologias certas nos locais certos; para mim, uma tecnologia não livre nunca é uma tecnologia certa. Eu chamo a isso uma contradicao -- tecnologias certas nos locais certos, mas, se nao forem livres ja' nao sao certas. Soas um bocado ao porco no "Animal Farm": "all technologies are equal, but some are more equals than others.".#
"I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | Não é uma contradição, é uma questão de que se eu não for exigente comigo próprio, então quem será? Eu não me limito a escolher qualquer coisa, não importa as consequências.
|
| | | | | Deixa-me acrescentar uma coisa àcerca de Java Beans: são no mínimo fabulosos. Mas a JVM não é adequada para o tipo de aplicações que construo, senão fazia o que já uma vez fiz: JNI para interfacear métodos em C com o Java. O meu problemna é este: fiz quase tudo até agotra com componentes Bonobo. Acho-os terríveis no que concerne à sua manutenção: acrescentar um método CORBA é um aborrecimento terrível. E então aceder ao mesmo método verificando CORBA_Env quanto basta (e nunca parece bastar) é terrível, mais no sentido de rotineiro e maçudo do que difícil. Concedo isto: o C não é uma boa linguagem para lidar com erros, visto não ter excepções integradas na linguagem. E verifiquei que usar Bonobo de Python é maravilhosamente simples. Mas continuo a ter de fazer os componentes em C. O que é aborrecido. Que alternativas existem? O que podemos fazer para melhorar a infraestrutura existente em Linux e estabelecer pontes entre os sistemas de componentes mais utilizados (KParts e Bonobo)? Francisco Colaço
|
| | | | Acho que há um projecto de tentar facilitar o uso de componentes, provavelmente até de forma possivelmente reutilizável tanto em gnome como kde. Não sei sobre os detalhes mas IIRC chama-se DBUS...
|
| | | | Bonobo e' construido em cima de CORBA. Toda a gente conhece CORBA. Bonobo nao e' complicado, CORBA em C e' que e' (ligeiramente) complicado. CORBA tem a principal vantagem de ser independente de plataforma e de linguagem de programaçao. Eu por exemplo tenho um projecto que usa Bonobo/CORBA em C e em Python ao mesmo tempo.
|
| | | | | Uma implementação séria e abrangente de algo similar ao DDE (Dynamic Data Exchange) do Windows... 3.0!! X-) Sim, eu sei. Se eu lesse isto à alguns anos atrás eu mesmo me daria um tapa... Mas hoje pouca coisa me faria mais feliz que poder copiar qualquer coisa numa aplicação Gnome e colar numa KDE, ou mesmo Windowmaker. Raios, que uma aplicação no console possa ser um cliente DDE de uma aplicação KDE!!! 8-) Adoraria ter este serviço servindo à qualquer aplicação POSIX. Eu sei que componentes são uma solução muito mais completa, e que implementam melhor estas funcionalidades. Mas um DDE seria bem mais simples de implementar no curto prazo, e me quebraria um galho federal... Agora deixem eu procurar algo para me proteger dos tomates, que eu sei que mereço ao menos uma tomatada nas fuças... 8-)
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | Viva o D-Bus, um clone gnomico do tão insultado DCOP.
|
| | | | Deixem-me só dizer em voz bem alta que OpenGL não é de todo detestado. É só, por vezes, preterido em função de DX por uma cobertura gratinada de ignorância decorada com MS-marketing.
Nunca utilizei Bonobo, mas ao ser implementado sobre CORBA, não tem a desvantagem de CORBA que é de ser bastante mais pesado (layer sobre layer) do que outras alternativas?
Já alguém olhou para XPCOM (www.mozilla.org/projects)? Sinceramt, fiquei bem impressionado. Entre outros exemplos, ver a rapidez com que montaram o novo browser sob um interface XUL (O Phoenix, agora Firebird, em breve a substituir a linha Moz 1.4).
Vejam isto, e os links no topo - vale bastante a pena imho: http://www.mozilla.org/projects/xpcom/
|
| |
|
