Ticket #490 (new melhoria)

Opened 11 years ago

Last modified 9 years ago

Iniciar as discussões sobre a nova API do Expresso

Reported by: amuller Owned by:
Priority: média Milestone: Backlog do Produto
Component: API Version:
Severity: média Keywords: api expresso
Cc: niltonneto wmerlotto diorgenesduarte WorkGroup:

Description

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.

Attachments

usar_msgs_locais.png Download (44.2 KB) - added by rafaelraymundo 10 years ago.
Revisão [2645]: Arquivamento local habilitado não funciona

Change History

comment:1 Changed 11 years ago by rodsouza

  • Type changed from defeito to tarefa

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.

comment:2 follow-up: ↓ 3 Changed 11 years ago by 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.

comment:3 in reply to: ↑ 2 Changed 11 years ago by 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, ...

comment:4 follow-up: ↓ 5 Changed 11 years ago by 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).

comment:5 in reply to: ↑ 4 ; follow-up: ↓ 6 Changed 11 years ago by 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.

comment:6 in reply to: ↑ 5 ; follow-up: ↓ 7 Changed 11 years ago by 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).

comment:7 in reply to: ↑ 6 ; follow-up: ↓ 8 Changed 11 years ago by 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?

comment:8 in reply to: ↑ 7 ; follow-up: ↓ 9 Changed 11 years ago by 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?

comment:9 in reply to: ↑ 8 Changed 11 years ago by 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.

comment:10 Changed 11 years ago by 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.

comment:11 Changed 11 years ago by niltonneto

  • Milestone Expresso 2.0 deleted

comment:12 Changed 10 years ago by wmerlotto

  • Owner todo mundo deleted

comment:13 Changed 10 years ago by wmerlotto

  • Milestone set to Expresso 2.1

comment:14 Changed 10 years ago by wmerlotto

  • Type changed from tarefa to melhoria

comment:15 Changed 10 years ago by wmerlotto

  • Milestone changed from Expresso 2.1 to Expresso 2.2

comment:16 Changed 10 years ago by rodsouza

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

phpgwapi/expressoAjax/expressoAjax.js

Committed revision r2047.

comment:17 follow-up: ↓ 19 Changed 10 years ago by 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.

comment:18 Changed 10 years ago by diogenesduarte

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

comment:19 in reply to: ↑ 17 Changed 10 years ago by 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.

Changed 10 years ago by rafaelraymundo

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

comment:20 Changed 10 years ago by 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.

comment:21 Changed 10 years ago by 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.

comment:22 Changed 9 years ago by niltonneto

  • Keywords 2.0 removed
  • Summary changed from Iniciar as discussões sobre API 2.0 do Expresso to Iniciar as discussões sobre a nova API do Expresso
  • Milestone changed from Expresso 2.2 to Expresso 3.0

Ó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.

comment:23 Changed 9 years ago by niltonneto

  • Version trunk deleted
  • Severity set to média
Note: See TracTickets for help on using tickets.