Iniciar as discussões sobre a nova API do Expresso

[amuller]

Já que nosso Trac já está bem freqüentado, inciei este ticket para partir os BrainStorm.

Criei esta página phpgwapi/2.0

Que tem intuito de listar demandas. Partindo delas especificar na prática o que precisa ser feito.

Este é o lugar para dar opinião, lá (a página) é o lugar para especificar as melhores.

[rodsouza]

Como esse assunto é extremamente polêmico para não dizer complexo, acredito que essa deve ser a melhor hora para começar a explaná-lo.

---

Antes de mais nada, é de conhecimento que atualmente existe uma série de código fonte sobresselente no ExpressoLivre?.

Essa parte de código que com o passar do tempo foi sendo inutilizada, devido a uma codificação muitas vezes arbitrária e totalmente desorientada, limitou a portabilidade do ExpressoLivre? além de retirar inúmeras características importantes herdadas do eGroupWare.

Com isso o ExpressoLivre? encontra-se na seguinte situação:

• a portabilidade do ExpressoLivre? é nula;
  
• não possui documentação alguma;
  
• na codificação, as ditas classes são no máximo abstração de coisa alguma;
  
• não temos um ambiente que contempla a demanda de um desenvolvimento colaborativo;
  
• a necessidade de mesclar códigos escrito por entidades diferentes é recorrente;
  
• a criação de novas funcionalidades é extremamente complicada;
  
• novos bugs afetam o que já foi homologado;
  
• é quase inviável o esforço necessário para manter a mais simples funcionalidade existente.

Não adianta empurrar tudo isso com a barriga para uma nova API, na verdade, essa situação está em um ponto crítico, onde estamos gastanto muito tempo correndo em círculos e quase nenhum com o desenvolvimento do software.

---

Levando em consideração a possibilidade de se criar uma API, precisamos identificar uma arquitetura de software que contemple nossa realidade, preferencialmente o mais abstrata possível.

Uma arquitetura sustentada em Design Pattenrs visando:

• estabelecer um vocabulário comum para a equipe de desenvolvimento expressar e discutir soluções;
  
• auxiliar na documentação e na compreensão de sistemas;
  
• preparar o software para reuso e evolução;
  
• instrumento para a refatoração de projetos de software.

Sendo que 'Padrões emergem, não são inventados'.
Assim não custa lembrar que uma arquitetura deve:

• separar especificação de implementação;
  
• modelos devem descrever o que um objeto pode fazer, não como aquilo é feito;
  
• programar para a interface e não para a implementação;
  
• preferir reuso por associação, não por herança. Herança é eficiente, mas expõe aspectos internos (“caixa branca”) a classes derivadas, que ficam presas a essa implementação.

E ainda que os padrões:

• um padrão está voltado para a resolução de um problema. Não é simplesmente uma descrição de princípios ou estratégias;
  
• um padrão está associado a um conceito comprovado. Não é baseado em teorias ou especulações;
  
• um padrão apresenta uma solução não-trivial. Soluções iniciais são derivadas da aplicação de métodos;
  
• um padrão descreve um relacionamento. Não é a descrição de um módulo.

Sendo que padrões de projeto tentam antecipar, na modelagem, a demanda que pode surgir em evoluções futuras do sistema, com isso buscando por robustez.

Nem todos os aspectos variantes de um projeto podem ser contemplados em uma solução. Padrões procuram isolar as causas comuns de “reprojetos” de software e descrever soluções para esses problemas.

Uma solução para um problema real pode combinar vários padrões.

---

E qual o objetivo de tudo isso?

Reorganizar software de modo que ele realize a mesma coisa de forma diferente, com isso facilitando sua evolução.

Estabelecer uma arquitetura possui o objetivo de reorganizar o projeto de forma que futuras alterações tenham menos impacto sobre o restante do sistema.

Além de que estabelecer uma arquitetura evita problemas existente quando a mesma se auto-cria devido a omissão dessa etapa primária na concepção do projeto.

[rodsouza]

Depois de todo esse "blah-blah-blah"...

Na minha opinião a utilização do eGroupWare já está totalmente depreciada.

Não sei o quanto é válido continuar com essa dependência pois como é de conhecimento de todos ela já demonstrou diversos problemas.

[wmerlotto]

Replying to rodsouza:

Depois de todo esse "blah-blah-blah"...

Na minha opinião a utilização do eGroupWare já está totalmente depreciada.

Não sei o quanto é válido continuar com essa dependência pois como é de conhecimento de todos ela já demonstrou diversos problemas.

Concordo plenamente contigo Rodrigo. Acredito que existem melhores alternativas (e código) do que o egroupware.

Porém, é uma mudança complicada, custosa e com certeza traumática... Acredito que poderíamos criar um fork desta discussão, onde de um lado continuamos a pensar no modelo ideal de api, codificação, módulos, ..., e do outro discutimos coisas mais factíveis em um curto espaço de tempo, como enxugar o código removendo o que não é utilizando do egw, dentre outras coisas... Acredito que assim teremos melhoras significativas no médio prazo e ainda estaremos cada vez mais próximos da situação ideal.

Acho muito importante pensar longe, discutir essa arquitetura ideal, pirar em novos conceitos, tecnologias, aplicações, ...

[amuller]

Eu admito que a minha propósta incial foi bem covarde, mas melhor do que nada.

Era só adaptar o que tem hoje para algo mais unificado. Essa seria a API 1.9 e não 2.0. Idealmente deveria ser como o Rodrigo falou.

A minha idéia é como a do Merlotto: uma API intermediária (que será rápida de implementar) Essa intermediária segue essa idéia colocada no wiki. O ExpressoMail? se tornou o módulo mais poderoso em termos de código. A idéia é pegar ele, jogar boa parte dele pra API (de forma que todos os módulos utilizam estes códigos).

[wmerlotto]

Replying to amuller:

Eu admito que a minha propósta incial foi bem covarde, mas melhor do que nada.

Era só adaptar o que tem hoje para algo mais unificado. Essa seria a API 1.9 e não 2.0. Idealmente deveria ser como o Rodrigo falou.

A minha idéia é como a do Merlotto: uma API intermediária (que será rápida de implementar) Essa intermediária segue essa idéia colocada no wiki. O ExpressoMail? se tornou o módulo mais poderoso em termos de código. A idéia é pegar ele, jogar boa parte dele pra API (de forma que todos os módulos utilizam estes códigos).

Maravilha! Uma solução intermediária é melhor do que nada mesmo e acredito que terá bons resultados.

[niltonneto]

Replying to wmerlotto:

Replying to amuller:

Eu admito que a minha propósta incial foi bem covarde, mas melhor do que nada.

Era só adaptar o que tem hoje para algo mais unificado. Essa seria a API 1.9 e não 2.0. Idealmente deveria ser como o Rodrigo falou.

A minha idéia é como a do Merlotto: uma API intermediária (que será rápida de implementar) Essa intermediária segue essa idéia colocada no wiki. O ExpressoMail? se tornou o módulo mais poderoso em termos de código. A idéia é pegar ele, jogar boa parte dele pra API (de forma que todos os módulos utilizam estes códigos).

Maravilha! Uma solução intermediária é melhor do que nada mesmo e acredito que terá bons resultados.

Com certeza, essa é a melhor solução para caminharmos para uma API limpa do Expresso. E como já estamos trabalhando para unificar nossos esforços , "colocando ordem na casa" no que diz respeito ao nosso ambiente colaborativo (SVN/Wiki/Trac), vamos por partes.
Portanto, após a finalização essas demandas mais urgentes, poderemos iniciar assim:

• Retirar da API códigos que não usados pelo Expresso;
  
• Unificar o framework Ajax existente nos diversos módulos (Mail, Agenda, Admin, etc) e jogar pra dentro dessa API.
• Renomear phpgwapi para outro nome (avaliar o impacto).

[rodsouza]

- Retirar da API códigos que não usados pelo Expresso;

Qual o objetivo de realizar esse procedimento?

- Unificar o framework Ajax existente nos diversos módulos (Mail, Agenda, Admin, etc) e jogar pra dentro dessa API.

Possuir um meio único de executar uma requisição seria muito bom.
Qual seria utilizado, o presente no ExpressoMail??

- Renomear phpgwapi para outro nome (avaliar o impacto).

Volta a indagação inicial, qual o objetivo?

[wmerlotto]

Replying to rodsouza:

- Retirar da API códigos que não usados pelo Expresso;

Qual o objetivo de realizar esse procedimento?

No meu ponto de vista, remover códigos inúteis podem facilitar a manutenção e diminuir a chance de problemas (e até falhas de segurança), já que o escopo é menor, além de reduzir os mbytes necessários para download, carregamento e execução do código...

- Unificar o framework Ajax existente nos diversos módulos (Mail, Agenda, Admin, etc) e jogar pra dentro dessa API.

Possuir um meio único de executar uma requisição seria muito bom.
Qual seria utilizado, o presente no ExpressoMail??

Poderíamos utilizar o que está pronto, só movendo de lugar, ou seja, mover o que está no ExpressoMail para API e posteriormente utilizar um framework específico, tipo  jquery (precisaria de um estudo/avaliação). Assim diminuímos novamente a quantidade de código para manter. Além disso, ganhamos com a padronização (facilitaria a criação de novos módulos), centralização de recursos (se funciona, funciona para todos os módulos, se não funciona, ferra todos os módulos...), diminuiria o uso de recursos dos dois lados (cliente e servidor), entre outros...

- Renomear phpgwapi para outro nome (avaliar o impacto).

Volta a indagação inicial, qual o objetivo?

Padronizar e iniciar a criação de uma API própria do Expresso?

[rodsouza]

Replying to wmerlotto:

No meu ponto de vista, remover códigos inúteis podem facilitar a manutenção e diminuir a chance de problemas (e até falhas de segurança), já que o escopo é menor,

Facilitar a manutibilidade do código concordo mas reduzir as chances de ocorrer problemas não é fato. Ao contrário, modificar o que está funcionando é mexer em casa de abelha.

além de reduzir os mbytes necessários para download

Isso não é aplicável.

carregamento e execução do código...

A redução em física do código não está diretamente ligado com o tempo gasto para processar o mesmo, a não ser que um arquivo de 10.000 linhas seja reduzido para 500 linhas ou menos. O tempo de processamento é afetado normalmente por uma lógica equivocada ou ainda dependências de serviços.

Poderíamos utilizar o que está pronto, ... mover o que está no ExpressoMail para API e posteriormente utilizar um framework específico ... Assim diminuímos novamente a quantidade de código para manter.

Realizar o mesmo procedimento mais de uma vez é correr atrás do rabo. Se for realizada alguma alteração que ela seja um trabalho só.

Além disso, ganhamos com a padronização

Essa é a intenção.

Padronizar e iniciar a criação de uma API própria do Expresso?

Novamente correr atrás do rabo.

E outra coisa, com todo o risco inerente a alteração de código, ainda mais quando o mesmo não possui nenhuma documentação, não é justificável realizar alterações pesadas no que está funcionando a contento, mesmo que esse funcionamento não seja o melhor de todos.

Esse dito emagrecimento do ExpressoLivre é exatamente o que o amuller vêm fazendo a algum tempo. E muito já foi feito, melhorando bastante várias coisas e obviamente criando problemas novos também ... rsrsrs ... nem tudo nessa vida é perfeito.

[amuller]

Um ponto acho que não tem como haver discordância.

O que sair de novo DEVE obrigatoriamente ser compatível com que existe sem reescrita total de código. Essa solução nova demandaria tempo muito grande e que agente não tem.

O tempo que agente está agora gastando pra implementar coisas novas não pode ser jogado fora (caso contrário essa API não vai entrar em produção nunca). É o mesmo problema do Calendário novo, uma coisa que está sendo desenvolvido do zero, mas ao mesmo tempo que a solução velha também recebe coisas novas. Agora a coisa ta assim e tem que ser assim. É igual um prédio com pessoas morando, não dá pra derrubar tudo e fazer denovo e deixar as pessoas na rua. Agente tem que reformar o prédio sem tirar as pessoas de dentro, de qualquer forma que seja.

Neste ponto o Calendario novo foi um erro! A mudança deve ser transparente para o usuário, ele não deve perder funcionalidades. A reescrita tem que partir do que existe, não partir do zero. Isso é uma infelicidade não ignorância, se não for assim é inviável. Quando percebi que isso era assim comecei a fazer a fusão de códigos do expressoCalendar com Calendar do egroupware e esse trabalho não terminou ainda (quem sabe porque foi percebido tarde demais).

Agora vamos nos pontos que eu acho que foram bom terem sido levantados.

Agente precisa de uma metodologia. Documentação, comunicação, e etc... são conseqüências da metodologia.

[rodsouza]

Corrigindo problema com URL na utilização do cExecuteForm.

phpgwapi/expressoAjax/expressoAjax.js

Committed revision r2047.

[diogenesduarte]

Pessoal, acho que esse ticket acabou por fazer deixar de funcionar o arquivamento local em alguma revisão(creio que na 1999). Faltou fazer as mudanças no objeto mail_sync.js, pois ao arquivar acontece o erro connector is not defined nas linhas do mail_sync.

[diogenesduarte]

Feito as mudanças na chamada em connector também na classe mail_sync na revisão [2062].

[rafaelraymundo]

Realmente o arquivamento local não está funcionando na revisão corrente [2645] apresentando a tela em anexo. Isso passou a ocorrer na revisão [1999].

Replying to diogenesduarte:

Pessoal, acho que esse ticket acabou por fazer deixar de funcionar o arquivamento local em alguma revisão(creio que na 1999). Faltou fazer as mudanças no objeto mail_sync.js, pois ao arquivar acontece o erro connector is not defined nas linhas do mail_sync.

[rafaelraymundo]

Revisão [2645]: Arquivamento local habilitado não funciona

[rodsouza]

Esse não será a única situação a ser enfrentada para o reestabelecimento do arquivamento local no trunk.

Sugiro que o reestabelecimento seja feito em etapas, ou seja, primeiramente na revisão citada após realizar o mesmo procedimento para a revisão corrente pois as alterações realizadas referentes ao ticket #1009 terão impacto significativo sobre a funcionalidade.

Apenas para recordar os senhores que isso ocorreu devido a vossa não utilização do trunk.

[rafaelraymundo]

Corrigido em [2676] - Reestabelecendo a funcionalidade de arquivamento local. Devido a todos os objetos tiverem sido extendidos foi necessário realizar testes e 'pular' os métodos que foram adicionados a todos os objetos. Foi usado as novas funções de ajax nas funcionalidades do arquivamento. Ainda estão sendo feitas correções para essa funcionalidade.

[niltonneto]

Ótima discussão. Acredito que possamos caminhar juntos nisso, dentro da versão 3.0. Vou alterar o título deste ticket para não causar mais confusão.