Discussion :

[eponette]

J'ai eu une discution avec un ami totalement converti aux applications 'légères' (cad celle via browser). Perso, je suis de l'ancienne école et donc encore très lié aux applications lourdes.

Quelqu'un peut-il me donner un bon apperçu du pour et du contre de chaque?

Merci

[Aurelien.Regat-Barrel]

Ton ami développe quel genre d'applications ?

[eponette]

Ton ami développe quel genre d'applications ?

Je ne sais pas trop. Il ne m'a montré qu'une application pour faire des pages webs via le web.

Personne n'a fait une comparaison assez objective entre les deux?

[Aurelien.Regat-Barrel]

Ben faudrait déjà pouvoir comparer. Je ne sais pas comment ne serait-ce que lire un fichier avec une application "légère" (si j'ai bien compris ce que c'est : HTML & Javascript).

[eponette]

Tu sais facilement lire un fichier. Evidemment, derrière il y a du php (ou java), XML, XSL, RDS, JavaScript,...

[Aurelien.Regat-Barrel]

Selon ce que j'ai compris, une application "légère" n'autorise que ce qui est côté client, donc celà exclue PHP & Cie. Pour Java, je vois pas en quoi c'est plus léger qu'une appli "lourde" (sans browser) en Java.
C'est pour ça que je suis curieux de savoir ce que développe son ami, comment il développe un jeu video, un éditeur de texte, un outil de compression, ...

[Médinoc]

Si j'ai bien compris au contraire, une application "légère" ne nécessite qu'un simple navigateur internet coté client (et uniquement avec HTML+js), et fait tous les traitements coté serveur; alors qu'une application "lourde" utilise un client spécifique ou une applet java coté client.

À moins que j'aie confondu avec les termes "client léger" et "client lourd". Si ce n'est pas la même chose, alors j'ai fait un contresens.

[eponette]

Ma définition de légère est que du côté client, il n'y a besoin que d'un browser et tout se passe du côté serveur (donc en Java, php, ...). Donc pas d'installation, de mise à jour, ... Intéressant pour des programme devant être utilisé par des centaines d'utilisateur.

J'ai vu un prototype d'une des applications, et c'est une application pour mettre à jour des pages web (style news, intranet). Il y avait un éditeur de texte intégré (dans le browser) qui permettait de faire la mise en page. il y avait moyen de changer (ajouter, enlever, déplacer) un genre de treeview,...

C'est un peu ce que fait XUL (de mozilla).

Personne n'a lu un artiche sur une analyse comparative des deux approches et dans quel contexte l'un à un avantage par rapport à l'autre? J'aimerais aussi connaître les tendances actuelles par rapport à l'un et à l'autre.

Merci pour votre participation à ce topic

[Aurelien.Regat-Barrel]

Ah ok. Tu parles de développement web alors. On administre le serveur web via des pages spéciales. C'est classique.
Quelle est la 2° approche, a base de client lourd ?

Ma définition de légère est que du côté client, il n'y a besoin que d'un browser et tout se passe du côté serveur (donc en Java, php, ...). Donc pas d'installation, de mise à jour, ... Intéressant pour des programme devant être utilisé par des centaines d'utilisateur.

*programme*, c'est là que je te suis pas. Un site internet, c'est pas un programme, enfin, pour moi en tous cas. Les possibilités d'un browser sont quand même limitées, et puis y'a le serveur derrière, qui doit supporter tes centaines d'utilisateurs, sans parler de la bande passante, etc... Pour moi c'est 2 mondes à part.

[eponette]

Pourtant de nombreuses sociétés font des applications actuellement en pur mode web. Cad un programme tourne sur un (ou plusieurs) serveur(s) et l'utilisateur fait tout son travail via browser.

par exemple, ContactOffice http://www.contactoffice.com est un exemple d'application 'web' qui pourrait être fait une client lourd (OutLook???)

Mais quand faire l'un et quand faire l'autre? ou est la limite de l'un et de l'autre?

[Aurelien.Regat-Barrel]

Outlook est dispo en version client léger avec Exchange (Outlook Web Access).
http://images.google.fr/images?q=Outlook%20Web%20Access%20&hl=fr&lr=&sa=N&tab=wi
Tout dépend de l'utilisation que tu veux en faire. Si tu dois travailler sur des données sur le serveur c'est parfait. Mais tu ne peux pratiquement rien faire en local.
Ce que tu cites c'est des applications type client-serveur multi-utilisateurs, avec gestion centraliée de document (serveur dédié). Les solutions web sont idéales pour cela (CMS), tant que:
- le volume des données à échanger n'est pas trop élevé (genre visualiser des fichiers géophysiques en 3D)
- le client léger est effectivement léger, et ne travaille pas en local
Par exemple, un serveur CVS (gestion de code source) peut être couplé à un serveur web afin de consulter le dépôt via une interface web. Par exemple:
http://webcvs.kde.org/
a côté de ça tu as plein de clients lourds, genre WinCVS:
http://www.wincvs.org/shots.html#WINCVS
Lequel est le mieux ? Réponse, comme souvent : ça dépend. Si c'est pour consulter ce qu'il y a sur le serveur, etc... le portail web fait l'affaire. Si c'est pour synchroniser une copie locale avec un dépôt distant, il faut le client lourd (car il faut manipuler des données locales).