Senhores,
É verdade que há uma tendência em migrar aplicações Web para Desktop? Uma empresa aqui em São Paulo já está fazendo isso, para um de seus clientes bem importantes. A justificativa, são as continuas falhas entre os diversos navegadores webs e por conseguinte um encarecimento e dificuldade na manutenção dos sistemas.
Nunca ouvi nada sobre isso. Pelo contrário… nuvem nuvem nuvem é oq eu ouço.
+1
Sempre ouvi falar o contrário disso. E isso pode ser facilmente constatado numa breve pesquisa de vagas para programador na grande SP.
+1
Há esta possibilidade sim, mas a razão não seria compatibilidade entre browsers, mesmo porque este é um problema hoje praticamente superado.
A principal razão pra voltar da web para o desktop seria acesso à aplicação.
Yeap: vocês leram certo. Pegar uma aplicação de fácil acesso e dificultar a coisa por questões de sigilo ou segurança. Já vi isto ser feito e quando você para pra pensar, faz lá algum sentido.
[quote=kicolobo]Há esta possibilidade sim, mas a razão não seria compatibilidade entre browsers, mesmo porque este é um problema hoje praticamente superado.
A principal razão pra voltar da web para o desktop seria acesso à aplicação.
Yeap: vocês leram certo. Pegar uma aplicação de fácil acesso e dificultar a coisa por questões de sigilo ou segurança. Já vi isto ser feito e quando você para pra pensar, faz lá algum sentido.[/quote]
Sério?
Putz, me lembro agora de uma série de furos em aplicações desktop. A primeira que me vem a cabeça era os arquivos ini, contendo a senha e o usuário do banco de dados. A segunda, é que esse usuário normalmente é master, podendo fazer qualquer alteração no banco de dados.
Me lembro que uma vez eu necessitava de acesso ao banco para fazer uma consulta e não tinha a permisão de acesso aquele banco, e o responsável não estava no setor no momento para permitir. O que eu fiz? Fui até uma maquina e abri o arquivo ini e obtive o acesso!
[quote=x@ndy][quote=kicolobo]Há esta possibilidade sim, mas a razão não seria compatibilidade entre browsers, mesmo porque este é um problema hoje praticamente superado.
A principal razão pra voltar da web para o desktop seria acesso à aplicação.
Yeap: vocês leram certo. Pegar uma aplicação de fácil acesso e dificultar a coisa por questões de sigilo ou segurança. Já vi isto ser feito e quando você para pra pensar, faz lá algum sentido.[/quote]
Sério?
Putz, me lembro agora de uma série de furos em aplicações desktop. A primeira que me vem a cabeça era os arquivos ini, contendo a senha e o usuário do banco de dados. A segunda, é que esse usuário normalmente é master, podendo fazer qualquer alteração no banco de dados.
Me lembro que uma vez eu necessitava de acesso ao banco para fazer uma consulta e não tinha a permisão de acesso aquele banco, e o responsável não estava no setor no momento para permitir. O que eu fiz? Fui até uma maquina e abri o arquivo ini e obtive o acesso![/quote]
Esta foi a justificativa que ouvi: dificultar acesso à aplicação.
Se for parar pra pensar, realmente faz lá algum sentido: de fato, se for desktop fica mais difícil descobrir via rede a existência da coisa.
No entanto o cara tem de tomar uma série de precauções para que a justificativa pela segurança não vire outro furo como você mencionou.
Já vi estas monstruosidades também. Tem coisa até pior: incluir senha no binário do executável por exemplo.
No entanto, se a coisa for BEM feita, e se a necessidade de segurança for REAL, a coisa começa a fazer mais sentido.
[quote=kicolobo][quote=x@ndy][quote=kicolobo]Há esta possibilidade sim, mas a razão não seria compatibilidade entre browsers, mesmo porque este é um problema hoje praticamente superado.
A principal razão pra voltar da web para o desktop seria acesso à aplicação.
Yeap: vocês leram certo. Pegar uma aplicação de fácil acesso e dificultar a coisa por questões de sigilo ou segurança. Já vi isto ser feito e quando você para pra pensar, faz lá algum sentido.[/quote]
Sério?
Putz, me lembro agora de uma série de furos em aplicações desktop. A primeira que me vem a cabeça era os arquivos ini, contendo a senha e o usuário do banco de dados. A segunda, é que esse usuário normalmente é master, podendo fazer qualquer alteração no banco de dados.
Me lembro que uma vez eu necessitava de acesso ao banco para fazer uma consulta e não tinha a permisão de acesso aquele banco, e o responsável não estava no setor no momento para permitir. O que eu fiz? Fui até uma maquina e abri o arquivo ini e obtive o acesso![/quote]
Esta foi a justificativa que ouvi: dificultar acesso à aplicação.
Se for parar pra pensar, realmente faz lá algum sentido: de fato, se for desktop fica mais difícil descobrir via rede a existência da coisa.
No entanto o cara tem de tomar uma série de precauções para que a justificativa pela segurança não vire outro furo como você mencionou.
Já vi estas monstruosidades também. Tem coisa até pior: incluir senha no binário do executável por exemplo.
No entanto, se a coisa for BEM feita, e se a necessidade de segurança for REAL, a coisa começa a fazer mais sentido.[/quote]
Sim, mas nesse caso por que não uma aplicação em uma intranet? Pessoamente eu não consigo pensar em bom motivo para uma aplicação deskto para questão de segurança. A não ser que aplicação funcione com um sistema de segurança bloqueando keyloggers e afins.
[quote=x@ndy][quote=kicolobo][quote=x@ndy][quote=kicolobo]Há esta possibilidade sim, mas a razão não seria compatibilidade entre browsers, mesmo porque este é um problema hoje praticamente superado.
A principal razão pra voltar da web para o desktop seria acesso à aplicação.
Yeap: vocês leram certo. Pegar uma aplicação de fácil acesso e dificultar a coisa por questões de sigilo ou segurança. Já vi isto ser feito e quando você para pra pensar, faz lá algum sentido.[/quote]
Sério?
Putz, me lembro agora de uma série de furos em aplicações desktop. A primeira que me vem a cabeça era os arquivos ini, contendo a senha e o usuário do banco de dados. A segunda, é que esse usuário normalmente é master, podendo fazer qualquer alteração no banco de dados.
Me lembro que uma vez eu necessitava de acesso ao banco para fazer uma consulta e não tinha a permisão de acesso aquele banco, e o responsável não estava no setor no momento para permitir. O que eu fiz? Fui até uma maquina e abri o arquivo ini e obtive o acesso![/quote]
Esta foi a justificativa que ouvi: dificultar acesso à aplicação.
Se for parar pra pensar, realmente faz lá algum sentido: de fato, se for desktop fica mais difícil descobrir via rede a existência da coisa.
No entanto o cara tem de tomar uma série de precauções para que a justificativa pela segurança não vire outro furo como você mencionou.
Já vi estas monstruosidades também. Tem coisa até pior: incluir senha no binário do executável por exemplo.
No entanto, se a coisa for BEM feita, e se a necessidade de segurança for REAL, a coisa começa a fazer mais sentido.[/quote]
Sim, mas nesse caso por que não uma aplicação em uma intranet? Pessoamente eu não consigo pensar em bom motivo para uma aplicação deskto para questão de segurança. A não ser que aplicação funcione com um sistema de segurança bloqueando keyloggers e afins.[/quote]
Acho que o que ele quis dizer é que o cliente é desktop. Com um servidor e webservices para esse cliente consumir é uma boa alternativa(acho que é até melhor que usar um navegador). Você tem a nuvem e o cliente desktop.
[quote=juliocbq]
Acho que o que ele quis dizer é que o cliente é desktop. Com um servidor e webservices para esse cliente consumir é uma boa alternativa(acho que é até melhor que usar um navegador).[/quote]
Pessoamente, eu não vejo porque! Se for usar webservices, o sistema seria remoto, o que cria os mesmos problemas de acesso via browser. Nesse caso, somente se os dados trafegados fossem encriptados. Ai sim faz sentido, mas não seria mais simples criar uma VPN e montar uma intranet?
[quote=x@ndy][quote=kicolobo][quote=x@ndy][quote=kicolobo]Há esta possibilidade sim, mas a razão não seria compatibilidade entre browsers, mesmo porque este é um problema hoje praticamente superado.
A principal razão pra voltar da web para o desktop seria acesso à aplicação.
Yeap: vocês leram certo. Pegar uma aplicação de fácil acesso e dificultar a coisa por questões de sigilo ou segurança. Já vi isto ser feito e quando você para pra pensar, faz lá algum sentido.[/quote]
Sério?
Putz, me lembro agora de uma série de furos em aplicações desktop. A primeira que me vem a cabeça era os arquivos ini, contendo a senha e o usuário do banco de dados. A segunda, é que esse usuário normalmente é master, podendo fazer qualquer alteração no banco de dados.
Me lembro que uma vez eu necessitava de acesso ao banco para fazer uma consulta e não tinha a permisão de acesso aquele banco, e o responsável não estava no setor no momento para permitir. O que eu fiz? Fui até uma maquina e abri o arquivo ini e obtive o acesso![/quote]
Esta foi a justificativa que ouvi: dificultar acesso à aplicação.
Se for parar pra pensar, realmente faz lá algum sentido: de fato, se for desktop fica mais difícil descobrir via rede a existência da coisa.
No entanto o cara tem de tomar uma série de precauções para que a justificativa pela segurança não vire outro furo como você mencionou.
Já vi estas monstruosidades também. Tem coisa até pior: incluir senha no binário do executável por exemplo.
No entanto, se a coisa for BEM feita, e se a necessidade de segurança for REAL, a coisa começa a fazer mais sentido.[/quote]
Sim, mas nesse caso por que não uma aplicação em uma intranet? Pessoamente eu não consigo pensar em bom motivo para uma aplicação deskto para questão de segurança. A não ser que aplicação funcione com um sistema de segurança bloqueando keyloggers e afins.[/quote]
Duas razões iniciais aparentes: desconfiança extrema e ignorância.
Mas depois que você vê algumas coisas muito sinistras ocorrerem você começa a entender perfeitamente o porquê.
[quote=x@ndy][quote=juliocbq]
Acho que o que ele quis dizer é que o cliente é desktop. Com um servidor e webservices para esse cliente consumir é uma boa alternativa(acho que é até melhor que usar um navegador).[/quote]
Pessoamente, eu não vejo porque! Se for usar webservices, o sistema seria remoto, o que cria os mesmos problemas de acesso via browser. Nesse caso, somente se os dados trafegados fossem encriptados. Ai sim faz sentido, mas não seria mais simples criar uma VPN e montar uma intranet?[/quote]Concordo com você, mas nem precisa de tanto… Um HTTPS já resolveria o problema de ataque do tipo man in the middle.
Eu creio que exista algum motivo por trás disso… Ou alguém está lucrando dinheiro por fora ou é alguém que teve uma má experiência em projetos http (geralmente com muito javascript), e aí tem essas opiniões radicais.
Honestamente o único motivo que eu vejo para um projeto desktop seria para quando o projeto necessita de muito recurso visual avançado: mapas 3d com diversas opções de interação com o usuário, ou coisas do tipo.
[quote=kicolobo][quote=x@ndy]
Sim, mas nesse caso por que não uma aplicação em uma intranet? Pessoamente eu não consigo pensar em bom motivo para uma aplicação deskto para questão de segurança. A não ser que aplicação funcione com um sistema de segurança bloqueando keyloggers e afins.[/quote]
Duas razões iniciais aparentes: desconfiança extrema e ignorância.
Mas depois que você vê algumas coisas muito sinistras ocorrerem você começa a entender perfeitamente o porquê.[/quote]
Só por ignorância, já que isso não vai realmente resolver o problema e existe ações bem mais simples que poderiam faze-lo!
[quote=Hebert Coelho][quote=x@ndy][quote=juliocbq]
Acho que o que ele quis dizer é que o cliente é desktop. Com um servidor e webservices para esse cliente consumir é uma boa alternativa(acho que é até melhor que usar um navegador).[/quote]
Pessoamente, eu não vejo porque! Se for usar webservices, o sistema seria remoto, o que cria os mesmos problemas de acesso via browser. Nesse caso, somente se os dados trafegados fossem encriptados. Ai sim faz sentido, mas não seria mais simples criar uma VPN e montar uma intranet?[/quote]Concordo com você, mas nem precisa de tanto… Um HTTPS já resolveria o problema de ataque do tipo man in the middle.
Eu creio que exista algum motivo por trás disso… Ou alguém está lucrando dinheiro por fora ou é alguém que teve uma má experiência em projetos http (geralmente com muito javascript), e aí tem essas opiniões radicais.
Honestamente o único motivo que eu vejo para um projeto desktop seria para quando o projeto necessita de muito recurso visual avançado: mapas 3d com diversas opções de interação com o usuário, ou coisas do tipo. [/quote]
Concordo. Sou do ambiente desktop e agora que estou começando a ve aventurar pelo ambiente web. Na no primeiro projeto web que participei, tive que me reinventar, pois estava acostumado com uma série de recursos disponiveis no ambiente desktop e que seria inviavel fazer para web. Optei pela simplicidade, e descobri que 90% dos sistemas não necessitam de todos os recursos que o deskto oferece. É uma questão purament cultural! O sistema não perde em funcionalidade devido ao ambiente, perde em firula-las! Aplicações desktop, para mim somente para sistema que necessitem fazer chamadas a api do sistema operacional ou que necessite de recursos gráficos avançadados, como você colocou.
[quote=Hebert Coelho][quote=x@ndy][quote=juliocbq]
Acho que o que ele quis dizer é que o cliente é desktop. Com um servidor e webservices para esse cliente consumir é uma boa alternativa(acho que é até melhor que usar um navegador).[/quote]
Pessoamente, eu não vejo porque! Se for usar webservices, o sistema seria remoto, o que cria os mesmos problemas de acesso via browser. Nesse caso, somente se os dados trafegados fossem encriptados. Ai sim faz sentido, mas não seria mais simples criar uma VPN e montar uma intranet?[/quote]Concordo com você, mas nem precisa de tanto… Um HTTPS já resolveria o problema de ataque do tipo man in the middle.
Eu creio que exista algum motivo por trás disso… Ou alguém está lucrando dinheiro por fora ou é alguém que teve uma má experiência em projetos http (geralmente com muito javascript), e aí tem essas opiniões radicais.
Honestamente o único motivo que eu vejo para um projeto desktop seria para quando o projeto necessita de muito recurso visual avançado: mapas 3d com diversas opções de interação com o usuário, ou coisas do tipo. [/quote]
Você consegue essa mesma funcionalidade com javascript. Os browsers suportam webgl. A vantagem da aplica’ão desktop é o software em si não depender de um servidor para funcionar pelo menos em modo offline. Em alguns casos é preferível fazer parte de um grande processamento no cliente e posteriormente enviar mastigado para o servidor. Existem dezenas de vantagens e motivos.
[quote=juliocbq][quote=x@ndy][quote=kicolobo][quote=x@ndy][quote=kicolobo]Há esta possibilidade sim, mas a razão não seria compatibilidade entre browsers, mesmo porque este é um problema hoje praticamente superado.
A principal razão pra voltar da web para o desktop seria acesso à aplicação.
Yeap: vocês leram certo. Pegar uma aplicação de fácil acesso e dificultar a coisa por questões de sigilo ou segurança. Já vi isto ser feito e quando você para pra pensar, faz lá algum sentido.[/quote]
Sério?
Putz, me lembro agora de uma série de furos em aplicações desktop. A primeira que me vem a cabeça era os arquivos ini, contendo a senha e o usuário do banco de dados. A segunda, é que esse usuário normalmente é master, podendo fazer qualquer alteração no banco de dados.
Me lembro que uma vez eu necessitava de acesso ao banco para fazer uma consulta e não tinha a permisão de acesso aquele banco, e o responsável não estava no setor no momento para permitir. O que eu fiz? Fui até uma maquina e abri o arquivo ini e obtive o acesso![/quote]
Esta foi a justificativa que ouvi: dificultar acesso à aplicação.
Se for parar pra pensar, realmente faz lá algum sentido: de fato, se for desktop fica mais difícil descobrir via rede a existência da coisa.
No entanto o cara tem de tomar uma série de precauções para que a justificativa pela segurança não vire outro furo como você mencionou.
Já vi estas monstruosidades também. Tem coisa até pior: incluir
senha no binário do executável por exemplo.
No entanto, se a coisa for BEM feita, e se a necessidade de segurança for REAL, a coisa começa a fazer mais sentido.[/quote]
Sim, mas nesse caso por que não uma aplicação em uma intranet? Pessoamente eu não consigo pensar em bom motivo para uma aplicação deskto para questão de segurança. A não ser que aplicação funcione com um sistema de segurança bloqueando keyloggers e afins.[/quote]
Acho que o que ele quis dizer é que o cliente é desktop. Com um servidor e webservices para esse cliente consumir é uma boa alternativa(acho que é até melhor que usar um navegador). Você tem a nuvem e o cliente desktop.[/quote]
isso mesmo! O que fiquei intrigado é que a empresa que está nesse processo de migracao de sistema web para desktop web é a cielo e tambem a master card. A empresa que trabalha no desenv de sistemas ja esta fazendo as migracoes!!
[quote=juliocbq][quote=Hebert Coelho][quote=x@ndy][quote=juliocbq]
Acho que o que ele quis dizer é que o cliente é desktop. Com um servidor e webservices para esse cliente consumir é uma boa alternativa(acho que é até melhor que usar um navegador).[/quote]
Pessoamente, eu não vejo porque! Se for usar webservices, o sistema seria remoto, o que cria os mesmos problemas de acesso via browser. Nesse caso, somente se os dados trafegados fossem encriptados. Ai sim faz sentido, mas não seria mais simples criar uma VPN e montar uma intranet?[/quote]Concordo com você, mas nem precisa de tanto… Um HTTPS já resolveria o problema de ataque do tipo man in the middle.
Eu creio que exista algum motivo por trás disso… Ou alguém está lucrando dinheiro por fora ou é alguém que teve uma má experiência em projetos http (geralmente com muito javascript), e aí tem essas opiniões radicais.
Honestamente o único motivo que eu vejo para um projeto desktop seria para quando o projeto necessita de muito recurso visual avançado: mapas 3d com diversas opções de interação com o usuário, ou coisas do tipo. [/quote]
Você consegue essa mesma funcionalidade com javascript. Os browsers suportam webgl. A vantagem da aplica’ão desktop é o software em si não depender de um servidor para funcionar pelo menos em modo offline. Em alguns casos é preferível fazer parte de um grande processamento no cliente e posteriormente enviar mastigado para o servidor. Existem dezenas de vantagens e motivos.[/quote]
Mas nesse caso, seria possivel fazer tudo o que você falou utilizando javascript. Nesse caso, desktop leva vantagem em termos de facilidade de programação, já que é um ambiente muito mais maduro para aplicações ricas! Desenvolver uma aplicação com os mesmos recursos, utilizando javascrip ou swing, por exemplo, swing levaria vantagem.
Existe a questão do acesso a API do SO, mas isso é exceção a regra.
Pessoalmente, eu acredito muito mais em uma aplicação hibrida do que fazer toda a apliacação para desktop, e eu programao para desktop. Por exemplo, na aplicação que estou trabalhando, é necessário que ela faça acesso a recursos do so, como uma porta serial. A aplicação então é híbrida, e estou usando applets para evitar problemas de atualização! Isso porque a parte que necessita de acesso ao SO é apenas uma pequena parcela do sistema e, por isso, não compensava perder todas as vantagens oferecidas por um sistema web e partir para um sistema desktop.
[quote=x@ndy][quote=juliocbq][quote=Hebert Coelho][quote=x@ndy][quote=juliocbq]
Acho que o que ele quis dizer é que o cliente é desktop. Com um servidor e webservices para esse cliente consumir é uma boa alternativa(acho que é até melhor que usar um navegador).[/quote]
Pessoamente, eu não vejo porque! Se for usar webservices, o sistema seria remoto, o que cria os mesmos problemas de acesso via browser. Nesse caso, somente se os dados trafegados fossem encriptados. Ai sim faz sentido, mas não seria mais simples criar uma VPN e montar uma intranet?[/quote]Concordo com você, mas nem precisa de tanto… Um HTTPS já resolveria o problema de ataque do tipo man in the middle.
Eu creio que exista algum motivo por trás disso… Ou alguém está lucrando dinheiro por fora ou é alguém que teve uma má experiência em projetos http (geralmente com muito javascript), e aí tem essas opiniões radicais.
Honestamente o único motivo que eu vejo para um projeto desktop seria para quando o projeto necessita de muito recurso visual avançado: mapas 3d com diversas opções de interação com o usuário, ou coisas do tipo. [/quote]
Você consegue essa mesma funcionalidade com javascript. Os browsers suportam webgl. A vantagem da aplicação desktop é o software em si não depender de um servidor para funcionar pelo menos em modo offline. Em alguns casos é preferível fazer parte de um grande processamento no cliente e posteriormente enviar mastigado para o servidor. Existem dezenas de vantagens e motivos.[/quote]
Mas nesse caso, seria possivel fazer tudo o que você falou utilizando javascript. Nesse caso, desktop leva vantagem em termos de facilidade de programação, já que é um ambiente muito mais maduro para aplicações ricas! Desenvolver uma aplicação com os mesmos recursos, utilizando javascrip ou swing, por exemplo, swing levaria vantagem.
Existe a questão do acesso a API do SO, mas isso é exceção a regra.
Pessoalmente, eu acredito muito mais em uma aplicação hibrida do que fazer toda a apliacação para desktop, e eu programao para desktop. Por exemplo, na aplicação que estou trabalhando, é necessário que ela faça acesso a recursos do so, como uma porta serial. A aplicação então é híbrida, e estou usando applets para evitar problemas de atualização! Isso porque a parte que necessita de acesso ao SO é apenas uma pequena parcela do sistema e, por isso, não compensava perder todas as vantagens oferecidas por um sistema web e partir para um sistema desktop.[/quote]
Pensa assim: Você tem em seus 10 clientes arquivos de 1 gb para fazer upload. Isso porque seu sistema deve funcionar em modo offline em alguns períodos, ou porque o fluxo em um estacionmento de um shoping é grande e se a intranet cair essas estações devem saber como agir. Se essas estações não tiverem autonomia de preprocessar, trabalhar offline, o servidor não aguenta toda essa quantidade de trabalho.
É um caso onde o desktop é vantajoso.
[quote=juliocbq][quote=x@ndy][quote=juliocbq][quote=Hebert Coelho][quote=x@ndy][quote=juliocbq]
Acho que o que ele quis dizer é que o cliente é desktop. Com um servidor e webservices para esse cliente consumir é uma boa alternativa(acho que é até melhor que usar um navegador).[/quote]
Pessoamente, eu não vejo porque! Se for usar webservices, o sistema seria remoto, o que cria os mesmos problemas de acesso via browser. Nesse caso, somente se os dados trafegados fossem encriptados. Ai sim faz sentido, mas não seria mais simples criar uma VPN e montar uma intranet?[/quote]Concordo com você, mas nem precisa de tanto… Um HTTPS já resolveria o problema de ataque do tipo man in the middle.
Eu creio que exista algum motivo por trás disso… Ou alguém está lucrando dinheiro por fora ou é alguém que teve uma má experiência em projetos http (geralmente com muito javascript), e aí tem essas opiniões radicais.
Honestamente o único motivo que eu vejo para um projeto desktop seria para quando o projeto necessita de muito recurso visual avançado: mapas 3d com diversas opções de interação com o usuário, ou coisas do tipo. [/quote]
Você consegue essa mesma funcionalidade com javascript. Os browsers suportam webgl. A vantagem da aplicação desktop é o software em si não depender de um servidor para funcionar pelo menos em modo offline. Em alguns casos é preferível fazer parte de um grande processamento no cliente e posteriormente enviar mastigado para o servidor. Existem dezenas de vantagens e motivos.[/quote]
Mas nesse caso, seria possivel fazer tudo o que você falou utilizando javascript. Nesse caso, desktop leva vantagem em termos de facilidade de programação, já que é um ambiente muito mais maduro para aplicações ricas! Desenvolver uma aplicação com os mesmos recursos, utilizando javascrip ou swing, por exemplo, swing levaria vantagem.
Existe a questão do acesso a API do SO, mas isso é exceção a regra.
Pessoalmente, eu acredito muito mais em uma aplicação hibrida do que fazer toda a apliacação para desktop, e eu programao para desktop. Por exemplo, na aplicação que estou trabalhando, é necessário que ela faça acesso a recursos do so, como uma porta serial. A aplicação então é híbrida, e estou usando applets para evitar problemas de atualização! Isso porque a parte que necessita de acesso ao SO é apenas uma pequena parcela do sistema e, por isso, não compensava perder todas as vantagens oferecidas por um sistema web e partir para um sistema desktop.[/quote]
Pensa assim: Você tem em seus 10 clientes arquivos de 1 gb para fazer upload. Isso porque seu sistema deve funcionar em modo offline em alguns períodos, ou porque o fluxo em um estacionmento de um shoping é grande e se a intranet cair essas estações devem saber como agir. Se essas estações não tiverem autonomia de preprocessar, trabalhar offline, o servidor não aguenta toda essa quantidade de trabalho.
É um caso onde o desktop é vantajoso.[/quote]
Mas ai é que tá, isso são situações especificas, o que não compensa desenvolver um sistema inteiro para desktop por que uma parte dele necessita dessa funcionalidade. Por isso falei da aplicação híbrida.