Bom, não sei dizer se JSON tem compatibilidade com XSLT, mesmo pq na ideia que dei o XSLT que tera praticamente o "trabalho pesado", mas se tu diz ser melhor me resta procurar se essa compatibilidade existe, pq a viabilidade de XSLT + XML eh fantastica, agora se misturar as tecnologias e obtermos um ganho de desempenho será melhor ainda, concordo que qualquer tanto de desempenho ganho eh vantagem, sem dúvida !!!
<br><br><br><br><div><span class="gmail_quote">Em 06/11/07, <b class="gmail_sendername">eden</b> <<a href="mailto:edencardim@gmail.com">edencardim@gmail.com</a>> escreveu:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 11/6/07, Lucas Mateus <<a href="mailto:lucasmateus.oliveira@gmail.com">lucasmateus.oliveira@gmail.com</a>> wrote:<br>> Bom, acho que eh bastante relevante e dependente do recurso de Hardware<br>> despendido. Não trocaria XML por outra tecnologia devido a compatibilidade
<br>> com JS e XSLT.<br><br>Com certeza não é mais compatível com JavaScript do que JSON<br>(JavaScript Object Notation), que é nativo ao JS.<br><br>> Mesmo pq nesse caso o CGI sera usado somente pra fazer<br>> consultas em BD ou similar, nada mais. Existe um painel para administração
<br>> de websites com quase 2 milhões de websites, escrito em CGI e Template e<br>> varias outras tecnologias envolvidas, não sei quantas requisições por minuto<br>> recebe, mas acredito ser mais bem mais de 20. A alocação de memória com
<br>> mod_perl era inviavel apesar do server ter 8GB de RAM =) tudo bem<br>> confesso, ele tbm tem 8 processadores Xeon aheuaheuaheuaheuaheuahuehau<br><br>Provavelmente havia vazamento de memória no sistema, o mod_perl tende
<br>a consumir a mesma quantidade de memória que o CGI já que em ambas as<br>tecnologias os processos possuem seu próprio espaço de memória. Essa é<br>outra desvantagem do CGI, como os processos não ficam residentes na<br>
memória, os problemas de vazamento ficam disfarçados.<br>Outra coisa, se você está consultando um BD, o overhead é maior ainda,<br>já que você vai precisar estabelecer uma conexão com o SGBD toda vez.<br>Quando você está lidando com muito tráfego, cada segundo que se
<br>economizar por requisição é importante.<br>Só é razoável considerar o uso de CGI em sistemas que não serão muito<br>solicitados, como interfaces administrativas e bugtrackers, e olhe lá.<br>O Bugzilla é Perl/CGI e este é um dos fatores pelo qual está perdendo
<br>mercado. É tão fácil usar FastCGI ou mod_perl que não entendo porque<br>ainda existem pessoas desenvolvendo sistemas baseados em CGI.<br><br>--<br><a href="http://edenc.vox.com">edenc.vox.com</a><br>_______________________________________________
<br>SaoPaulo-pm mailing list<br><a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br><a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a><br></blockquote></div>
<br>