Re: [Notes2-team] O modelo de desenvolvimento do Notes...

[Thiago K. <ko...@ms...>]

Bom, continuo dizendo que a melhor opcao seria o "cross-plataforma!" 
claro!!.. seria o ideal, o
mais rapido e melhor para nós...

eu havia dito que se todos achassem que no futuro isso talvez poderia nos 
trazer algum tipo
de problema sério (que talvez só encontrariamos mesmo na hora do 
desenvolviemento) e com
isso, nos dando ainda mais trabalho e atrazando o desenvolvimento, seria 
melhor ter um
codigo para cada sistema!

mas como o anderson está muito otimista com a cross-plataforma, entao
acho que devemos confiar nele.. tambem acho que é a melhor forma de
desenvolver o notes para as duas plataformas, mas como eu nunca desenvolvi
nada para as duas plataformas antes, tinha ficado é com o pé atras!!

abraços,
Thiago Koguta


	-----Mensagem original-----
	De: Anderson Barbieri [mailto:no...@ig...]
	Enviada em: quarta-feira, 2 de julho de 2003 21:45
	Para: Notes Dev List
	Assunto: [Notes2-team] O modelo de desenvolvimento do Notes...



	Os 3 modelos...

	Olá pessoal. Nos últimos e-mails uma discussão muito importante vem tomando 
corpo e acho que chegou a hora de incluirmos todos (não apenas os 
desenvolvedores) nela para que possamos tomar uma decisão e seguirmos em 
frente.

	A discussão é sobre qual modelo de desenvolvimento vamos utilizar. Apesar 
de parecer algo para programador, na verdade não é - o modelo escolhido traz 
conseqüências para todo o futuro do Notes e, portanto, conseqüências para o 
planejamento que temos discutido. Pelos e-mails que chegaram, temos 3 
modelos diferentes e teremos que escolher um deles. Vou tentar explicá-los a 
seguir do modo que sei. Por favor, leiam e me corrijam onde for quiserem.

	1) Dois códigos fonte: um exemplo deste modelo é o M$ Office. Dois códigos 
fontes diferentes são mantidos e quando capacidades novas são implementadas 
em um precisam ser depois traduzidas para o outro fonte. Os dois fontes 
possuem alguma semelhança, mas também muitas diferenças, pois cada um deles 
segue as APIs e padrões específicos de cada sistema operacional. O M$ Office 
no windows é totalmente integrado ao Windows por causa disto. O M$ Office do 
Mac também é bastante integrado ao sistema operacional. Por um lado a forte 
integração aos sistemas operacionais diminuí a curva de aprendizado para 
pessoas acostumadas com aquele sistema operacional e, algumas vezes, traz 
algum aumento de performance. Por outro lado, usuários que usam o programa 
nos dois sistemas operacionais terão que reaprender algumas coisas do 
programa, já que ele não é igual nos dois sistemas operacionais. Além disso, 
como isto leva a desenvolver quase dois programas ao mesmo tempo, o 
desenvolvimento acaba sendo demorado e laboroso. Eu vejo este modelo sendo 
muito adotado por empresas como M$, Qualcom, Macromedia e Adobe (se bem que 
estas duas últimas não integram seus produtos tanto ao OS, preferindo manter 
muitas semelhanças entre as versões para Mac e Win de seus produtos). Por 
causa de todo o trabalho a mais que este modelo de desenvolvimento gera as 
empresas mantém duas equipes distintas de desenvolvimento - uma para cada 
código fonte. Outro porém deste modelo é que as versões costumam ter datas 
de lançamento bastante diferentes - é normal que o produto para Mac esteja 
na versão 2.1 e que a versão para windows já esteja na versão 3 ou 
vice-versa. No nosso caso este modelo nos daria uma vantagem a mais: não 
precisaríamos distribuir a QT no windows (o que significa 2 ou 3 Mbs a 
menos).

	2) IFDEFs: este modelo também traria para nós a vantagem de não precisar 
distribuir a biblioteca QT. Na realidade ele não chega a ser tão diferete do 
modelo 1: usa-se apenas um código fonte, pois através dos famosos ifdefs 
(*IDEF é uma instrução que permite que você use um pedaço do fonte ou outro 
dependendo de certas condições podendo assim, por exemplo, usar certo trecho 
de código no linux e outro diferente no windows*) os trechos específicos 
para cada sistema operacional podem ficar juntos. Este modelo não é tão 
trabalhoso quanto o anterior, mas por causa da grande quantidade de ifdefs 
no código este acaba ficando menos claro. Mas com algumas políticas de 
desenvolvimento os ifdefs podem ser "escondidos" e a clareza do codigo pode 
ser mantida em boa parte do fonte. Parece um bom modelo. Mas no nosto caso 
específico ele tem um problema - por causa de certas diferenças entre o 
linux e o windows (na realidade entre a CLX e a VCL, para quem programa em 
Delphi) não teremos como implementar temas e skins do modo como vinhamos 
pensando. (Até existe uma forma, mas teríamos que usar algo do modelo 1, 
parte do fonte teria que ser específico para cada plataforma.) Temos que 
pesar então o quão importante é para nós a interface do Notes ser 
configurável.

	3) Bibliotecas cross-plataforma: vocês conhecem esta solução de softwares 
abertos como OpenOffice e Mozilla. É a que eu tenho visto ser empregada nos 
softwares livres mais novos. Às vezes penso que o Java da Sun e o .Net da M$ 
derivaram suas idéias deste modelo. A idéia aqui é basear toda a construção 
do software em bibliotecas que sejam multiplataforma ao invés de usar as 
APIs providas pelo sistema operacional. Na verdade, este modelo deixa o 
trabalho de adaptar-se as APIs dos sistemas operacionais para as 
bibliotecas. Como o trabalho chato fica com os desenvolvedores da biblioteca 
esta me parece ser a forma mais rápida e menos trabalhosa de desenvolver um 
aplicativo multiplataforma. Claro que há alguns problemas: A. você deve 
distribuir as bibliotecas junto com o software. No nosso caso isto significa 
que teríamos que distribuir a QT no windows (no linux sempre teremos que 
distribuí-la). B. se a biblioteca tiver alguma falha em algum dos sistemas 
operacionais o desenvolvedor depende do desenvolvedor da biblioteca para 
corrigir o erro (no nosso caso é assim, mas o mozilla p. ex. não sofre deste 
problema por desenvolver as suas próprias bibliotecas) C. os 
desenvolvedores, normalmente acostumados com as APIs de algum sistema 
operacional precisam aprender as APIs da biblioteca (não é o nosso caso, já 
que a Borland fez as APIs ficarem na maior parte das vezes iguais a que 
usamos no windows ou disponibilizou alguma forma do reaprendizdo não ser 
necessário). No nosso caso acho que este é o modelo que permitiria o 
desenvolvimento mais acelerado e também a interface mais customizável. Por 
outro lado, os controles da QT tem algumas diferenças dos controles do 
windows - o que pode causar alguma estranhesa em algum usuário, por mais que 
todos os controles sejam fáceis de usar.

	São estes os três modelos e os prós e contras que conheço deles. Qual vocês 
acham que devemos usar? Aguardo os argumentos de vocês!

	Anderson

	--
	Anderson R. Barbieri
	---------------------
	Coordenador do Projeto Notes - Notepad Replacement
	http://notes.codigolivre.org.br * no...@ig...

_________________________________________________________________
MSN Hotmail, o maior webmail do Brasil.  http://www.hotmail.com