[flisol-devel] Novo Sistema de Registro

Maxx Fonseca maxxfonseca at gmail.com
Fri Dec 7 03:00:24 BRST 2007


Olá Pessoal,
	vamos por partes, ok?
Peter Eisinger wrote:
> (...)
> 
> Creo que antes de pensar en el commit, deberíamos organizarnos. Maxx ya 
> sabe las tareas que tengo para con el Sistema FliSys. Una es terminar 
> con la traducción al español, es lo mas urgente. Para así la semana 
> entrante invitar a que lo vean y utilicen. Difundirlo y atraer a más 
> interesados y voluntarios.
> 
> Luego evaluar conveniencia de continuar manteniendo MoinMoin y hasta que 
> punto  nos conviene evitar el upgrade de MoinMoin y migración a nuevo 
> server versus wikipedia en nuevo VPS. Creo que la mayoría de las 
> opiniones coinciden en lo segundo.
> 
> Al FliSys no le vendría mal tener 2 módulos para ser utilizados en los 
> wikis mencionados. Creo depende de voluntades y voluntarios. Si olvidar 
> factor tiempo.
> 
> Dejemos ahora oír la voz del team leader de FliSys, nuestro amigo Maxx!

	Team Leader de FliSys (Peter) e Líder (Igor), obrigado :-)
	Estive analisando várias formas de como poderíamos criar um padrão para 
os formulários de registros e estatísticas independente de wikis ou 
sistemas. Gostaria da opinião de todos.
	1) Formulário de Registros:
	Um form com campos texts, selects e checkboxs pré-definidos que apenas 
enviam o conteúdo para o FliSys. Simples ! Este formulário teria por 
obrigação ter campos do tipo hidden com os seguintes conteúdos: País, 
Estado, Cidade e email do coordenador local. Como é usado em um LDAP 
"email=E-Mail,ou=Cidade,ou=Estado,ou=Pais", por exemplo: 
"email=Mail em _Maxx_com,ou=Campinas,ou=SP,ou=Brasil"
	1.1) Possibilidade 1 (centralização):
	O FliSys irá verificar a integridade dos dados e registra-lo no DB 
correspondente à cidade.
	1.2) Possibilidade 2 (descentralização):
	O FliSys enviaria os dados em um formato de arquivo input para o e-mail 
do coordenador local, que, importaria "manualmente" os dados em seu 
FliSys local.
	1.3) Possibilidade 3 (descentralização):
	O FliSys registra o form e envia um aviso (e-mail) ao coordenador 
local. O coordenador local levanta seu FliSys e faz uma sincronização 
dos novos dados com o FliSys "server".
	1.4) Página de Erros:
	Para a página de erros, em caso de digitação incorreta e campos 
obrigatórios não preenchidos, temos outras 2 possibilidades.
	1.4.1) Possibilidade 1:
	O form envia em conjunto com o dados dois campos tipo hidden, um para 
em caso de erros (no formato: http://servidor_wiki/err) e outro em caso 
de sucesso (no formato: http://servidor_wiki/ok)
	O erro será acompanhado de uma ID. A ID do erro irá definir qual foi o 
erro encontrado pelo FliSys e a wiki imprime a mensagem correta na tela 
para o visitante.
	Por exemplo: http://server_wiki/err?id=0
	ID = 0 - Poderia ser NOME não informado
	ID = 1 - E-Mail não informado, etc.
	1.4.2) Possibilidade 2:
	O FliSys retorna apenas ERR [ID] ou OK e a wiki trataria de 
redirecionar o visitante para a página correta.
	A ID do erro é conforme explicado acima.
	2) Estatísticas:
	Para as estatísticas, o cenário é um pouco mais simples e ainda temos 2 
possibilidades também. Para isso a wiki deve enviar uma string com o 
filtro que deseja aplicar (Estatíticas por cidade, pais, geral, etc).
	O formato da string seria algo como:
	http://server_flisys/statistics.php?[PAIS]&[ESTADO]&[CIDADE]
	Se apenas [PAIS] for enviado, então o FliSys retorna as estatísticas 
por país. Se apenas [PAIS]&[ESTADO] for enviado, então o FliSys retorna 
as estatísticas do ESTADO selecionado e se a string completa for 
enviada, então o FliSys retorna as estatística da CIDADE selecionada. E 
caso não seja informado nada na string, então o FliSys retorna as 
estatísticas global.
	2.1) Possbilidade 1 (XML):
	O FliSys imprime na tela um XML contendo as estatísticas selecionadas 
pela string.
	2.2) Possibilidade 2 (DIRECT):
	O FliSys envia para uma página destino os dados das estatísticas 
selecionadas pela string no formato:
	http://server_destino/page?campo1=xxxx&campo2=xxxxxx,....
> 
>> Peter> Lamentablemente por imposición del proveedor del VPS, es el 
>> único que
>> Peter> tiene acceso al servidor.
>>
>> Si, eso fue muy difícil el año anterior.
>>
>> Peter> Lógicamente por mejor buena voluntad que le ponga, no puede  
>> hacer todo solo.
>> Peter> Tenemos a disposición el VPS ofrecido gentilmente por Cecilia
>> Peter> Contreras. De más está decir que apremia una pronta migración. 
>> Debemos
>> Peter> terminar de evaluar las alternativas, planificar y ejecutar.
>>
>> Creo que la replica en varios servidores y ayudarnos con el DNS
>> sería algo muy bueno, sobre todo si logramos un prerendered model.

	Replica de servidores nem sempre é possível, se está pensando 
seriamente nisso, então precisamos levantar quais são os serviços e se 
permitem que se repliquem para não haver dados corrompidos, 
multiplicados ou até mesmo faltando partes.
>>
>> Peter> Con este VPS ya no tenemos la imposición de que faw sea el único
>> Peter> responsable. Si faw se enferma ¿que hacemos?
>> Peter>
>>
>> Estamos totalmente de acuerdo, debemos en lo posible evitar depender
>> de una sola persona en cualquier sentido. No por falta de confianza
>> en la capacidad de faw, si no por la restricción de tiempo y
>> seguridad.

	Conforme o Peter me passou, estou vendo com um datacenter de uma 
universidade daqui de Campinas e eles se mostraram muito interessados em 
disponibilizar um servidor dedicado para nós. Ainda falta a parte 
burocrática mas acredito que é apenas uma questão de mais alguns dias 
para termos um servidor dedicado para o Flisol.
[]'s
Maxx


More information about the flisol-devel mailing list