Discussion :

[theMonz31]

salut rattlehead

Je pense que si les stand alone / deconnecté disparaissait ca serait une regression pour moi car cela voudrait dire que tout serait centralisé...

Tu voudrais lancer un logiciel, tu ne pourrais pas sans passer par internet
(et quid si t'as pas de reseau ? )

Tu veux te faire un jeu ? bjr les perfo si le jeu n'est que sur internet sans
exe tournant vraiment sur ta machine

Et perso, quand je vois comment on s'emmerde avec les sessions sous Asp.Net, je suis bien content de faire du dev de stand alone ou Client/Serveur hors Web

The Monz, Toulouse

[Acropole]

Un des gros problèmes du net c'est que, par exemple, faire la comptabilité de la société sur un browser et un logiciel hébergé chez google ou microsoft, bonjour la confidentialité.
A la rigueur, en réseau local, mais envoyer la compta (salaires, factures, etc...), des devis, des codes sources (et autres secrets de fabrication) sur internet c'est carrément suicidaire.

[rattlehead]

disons que le mode asp par exemple pour la compta ou la paie ca te permet de ne pas te soucier d'avoir des competences en paie ou en compta. j'ai bossé à l'élaboration d'un de ces asp. Mais ca met du temps à prendre et les gens ont effectivement une réticence à mettre ce genre de données chez une boite que tu ne connais pas trop.

theMonz31 je suis d'accord avec toi. je bosse dans le web et je me dis qu'on demande trop de choses à ce pauvre navigateur et que les contraintes sécurité session et autres sont trop chiantes à gérer. sans compter que quand tu fais du dev tu ne sais jamais pourquoi ca ne s'affiche pas pourquoi ca plante etc....
du coup j'aimerais bien quitter ce monde et faire plutot des librairies.

[yphilogene]

Sinon, dans le projet sur lequel je travaille (en ligne sur kizoa.fr), on utilise Flex et bientôt Air. Bon, je m'occupe de la partie serveur, en Java, donc mon expérience de Flex est limitée.
Ca a le mérite d'être mûr, contrairement à Silverlight ou JavaFX, mais je trouve ça peu performant (et c'est un euphémisme) et franchement gourmand, tant en mémoire qu'en CPU. Quand on a testé la première fois l'application sur MacOS X/Safari, ça faisait peur tellement c'était lent...
Sans parler des problèmes de compatibilité entre les versions de Flash : le plug-in Linux pour Flash 9 marche vraiment très mal (impossible de faire tourner notre appli Flex dessus, par exemple) et Flash 9 embarque 2 runtimes d'execution Actionscript distincts, pour AS2 et AS3. C'est un peu bancal, comme manière de fonctionner, je trouve. J'ai peur qu'Adobe ne prenne plein les dents quand Microsoft et Sun débarqueront vraiment sur le marché...

En voilà un post intéressant... Flex/AIR ne serait donc pas si prometteur que le marketing veut bient essayer de le faire croire...

Concernant le débat "applications standalone" vs "applications web", je pense que les deux continueront à exister et que les "applications web riches" visent à proposer un intermédiaire. Charger une application à partir d'un serveur comme on peut le faire avec Java Web Start permet à la fois d'avoir une application ergonomiquement équivalente à une "application standalone" se déployant comme une "application web" (mise à jour automatique de la machine virtuelle). Il faut "simplement" que JavaFX apporte son lot d'amélioration au tout avec une optimisation du temps de chargement et du temps nécessaire au développement d'applications simples (mais ergonomiquement puissantes).

Pourquoi ne pas choisir la solution client riche dans tous les cas? Principalement pour le travail en mode déconnecté je pense. Même si l'application propose des fonctions de synchronisation de contenu, cela peut être gênant de ne pas pouvoir utiliser l'application quand on voyage dans un train par exemple sans être connecté au réseau d'entreprise.

Croyez-vous qu'il soit envisageable de conserver sur le poste client une application chargée comme un applet? Autrement dit, on charge l'application, les données manipulées peuvent être copiées en local pour future synchonisation, mais l'application également, sans pour autant qu'elle soit réellement installée sur le poste comme une application standalone. Ce serait top ça non? En tout cas, je n'ai jamais vu ce type de comportement jusqu'à présent. Et vous?

[berceker united]

Je trouve que sur le marché du le client riche Adobe à un peut merdé avec Flash. En effet, Flash embarque déjà un sérieux baguage. Je comprend pas pourquoi ils se sont pas axé dessus pour l'ouvrir un peut plus ou la création d'une framework.
Pour Ajax, je pense qu'il y a eu une sorte d'erection entre fin 2006, début 2007. Après, il y a eu une sorte de feed-back plutôt négatif car beaucoup ont trouvé des limites à cette technologie. Certe, des grosses société y ont fait de sacré application avec techno. Google sans le nommé. Mais beaucoup s'y sont cassé les dents et ont fait marche arrière très rapidement.
Il y a une voie qui souvre qui est le Web Service. Le moteur est sur le serveur d'application et l'application graphique reste sur le poste client.

[ner0lph]

L'enjeu, c'est de faire des applications qui vont pouvoir fonctionner en ligne ET hors ligne. Un exemple : On pourrait facilement imaginer un traitement de texte qui fonctionnerait en ligne, comme Google Documents, mais qu'on pourrait aussi utiliser hors ligne. L'application sauvegarderait alors le travail en local et se synchroniserait toute seule avec le serveur dès que le réseau serait à nouveau disponible.

Normalement, ça sera le cas avec Firefox 3…

[eclesia]

encore un +1 pour la solution JavaWebStart.

Dans la derniere version de l'IDE Netbeans, on bascule en quelques click de l'application standalone à l'application JWS (signature des jar compris).


Personnellement je n'aime pas les client "riche" du genre php/asp+javascript. c'est une horreur. Un exemple ou cela à été poussé à l'extreme c'est pour Oracle 10g, le panneau de controle facon page web... c'est immonde, c'est long et on s'y perd.

Ce genre d'application web ne vaudra jamais une interface standalone enormement plus dynamique et à l'ergonomie cent fois supérieur.

[berceker united]

encore un +1 pour la solution JavaWebStart.

Dans la derniere version de l'IDE Netbeans, on bascule en quelques click de l'application standalone à l'application JWS (signature des jar compris).


Personnellement je n'aime pas les client "riche" du genre php/asp+javascript. c'est une horreur. Un exemple ou cela à été poussé à l'extreme c'est pour Oracle 10g, le panneau de controle facon page web... c'est immonde, c'est long et on s'y perd.

Ce genre d'application web ne vaudra jamais une interface standalone enormement plus dynamique et à l'ergonomie cent fois supérieur.

Pour Oracle 10g, c'est pas la technologie qu'il faut incriminer mais ceux qui ont mal développé cette application. Quand tu regardes ce que google à fait il y a un quand même du bon.

[eclesia]

Pour Oracle 10g, c'est pas la technologie qu'il faut incriminer mais ceux qui ont mal développé cette application.

...autrement dit, tu affirmes que les developpeurs d'Oracle qui ont fait ca sont des n...

tu ne crois pas que tu es allé chercher un argument tiré par les cheveux la?

Sans pour autant dire que ceux qui ont fait ca sont mauvais, cette interface web est complete (meme trop). Mais même en étant sur le serveur ca reste affreusement lent et peu maniable comparé à une application standalone.

[ultimatemanu]

Salut à tous, côté Flash et DHTML, je trouve personnellement l'approche OpenLaszlo intéressante. On peut déployer une application en Flash ou DHTML, c'est au choix au moment de la compilation , même si le deploiement DHTML est encore une fonctionnalité bétâ. L'application Flash est compatible avec Flash dès la version 7. On peut faire plein de trucs, faire fonctionner l'appli avec des jsp, du PHP, en fait avec tout ce qui peut retourner du XML à partir d'un base de données.
Pour moi, les applications clients légers ont donc un bel avenir devant elles, surtout avec les vitesses de connexion qui augmentent pas mal depuis qqs années.

[yphilogene]

encore un +1 pour la solution JavaWebStart.

Dans la derniere version de l'IDE Netbeans, on bascule en quelques click de l'application standalone à l'application JWS (signature des jar compris).

Peux-tu expliciter à quoi sert la signature des fichier .jar? Est-ce pour la sécurité par rapport à l'accès aux données du poste client?

[ludosoft]

Peux-tu expliciter à quoi sert la signature des fichier .jar? Est-ce pour la sécurité par rapport à l'accès aux données du poste client?

Oui, l'idée c'est de certifier la provenance de l'application afin de lui accorder des droits sur le poste client (accès au système de fichiers, réseau, périphériques locaux, etc.).

[ludosoft]

Bonjour à tous,

OUF ! Je ne suis pas le seul à penser que vouloir faire une appli desktop dans un navigateur avec AJAX c'est un peu comme vouloir couper du beurre avec un tourne-vis... Dans la société pour laquelle je travaille, j'ai toujours refusé de monter des usines pleines de javascript. Je préfère une page légère et bien conçue qui se recharge 10 fois plutôt qu'une page sur-vitaminée qui, « oh zut le réseau à planté, ah c'est revenu mais la page est bloquée... Ca fait quoi si je fais F5 ? ». Alors arrêtons de confondre navigateur et machine virtuelle. Une appli desktop dans un navigateur ? C'est pas fait pour ça bazar ! Du moins dans l'état actuel des standards...

Je dirais que, à mon avis, JavaWebStart va vraiment dans le bon sens. On profite de la puissance du poste client, on a pas de problème de déploiement, c'est transparent pour l'utilisateur et ça permet de faire aussi bien du mode connecté que déconnecté (sous réserve de pouvoir embarquer assez d'outillage comme un BDD locale par ex).

Java, Flash, SilverLight, OpenLaszlo, ... Moi j'ai de plus en plus peur que mon navigateur explose avec toutes ces machines virtuelles. Pourvu que je ne tombe pas sur une page avec une appli SilverLight, de la pub en Flash et un petit module de chat en Java ! Pauv' bête...

Je pense qu'il faut laisser les applis desktop au desktop et travailler plutôt sur leur déploiement. Quand aux « pages HTML », faisons évoluer les standards pour faciliter la programmation de leur ergonomie et pourquoi pas faire évoluer leur modèle client/serveur vers quelque chose de plus peer-to-peer ?

[toomsounet]

J'ai une question. Est ce que applis du genre google apps (tableur etc) s'exécutent dans un seul processus (le navigateur) ? C'est pas très bon si une des applis plante au risque de faire planter aussi les autres.

[_Mac_]

Tout pareil que ludosoft

toomsounet : d'où qu'il faut démarrer IE depuis l'icone sur le bureau et pas juste faire une nouvelle fenêtre !! Pour Firefox, c'est plus embêtant, tout fonctionne effectivement dans le même processus même en cliquant sur l'icone. D'où effectivement que si une appli plante et que t'es obligé de killer Firefox, t'as perdu tout ton boulot

[Lomig]

Ajax, c'est bluffant. Mais qui est le client lourd ? Celui qui a des codes de différents languages de script imbriqués (je sais il existe des framworks et des templates...) ou celui qui a une syntaxe claire et unique ?
Ce n'est pas pour troller mais l'expression "client leger" n'est-elle pas finalement trompeuse ? Il y a quand même un petit côté marketing dans tout cela...
A chaque problème une solution et un language.
Les appli web ont un avantage sur les autres, elles sont difficilement copiables et partageables.

[yphilogene]

et pourquoi pas faire évoluer leur modèle client/serveur vers quelque chose de plus peer-to-peer ?

Qu'est-ce que tu entends par peer-to-peer? Une architecture avec un serveur central de coordination et des postes clients qui font aussi office de serveur de données? On sort un peu de la discussion client riche là...

Connaissez-vous une solution équivalente à Java Web Start proposée par d'autres éditeurs ou est-ce que Java Web Start est le seul sur le marché à fournir ce processus de déploiement d'une application?

[yphilogene]

Les appli web ont un avantage sur les autres, elles sont difficilement copiables et partageables.

Peut-on en dire autant d'une application Java Web Start?

Pour moi, le terme "client léger" désigne les applications ne nécessitant qu'un navigateur basique, sans même Javascript, mais c'est un peu extrême car effectivement, on n'en retrouve plus beaucoup et le terme "client léger" a tendance à phagociter l'ensemble des applications web visibles aujourd'hui.

Je pense qu'il faut oublier les termes "client léger" et "client lourd" pour aller plus loin dans cette discussion en imaginant ce que pourrait être le "client riche", cette espèce de modèle d'application qui tente de reprendre le meilleur des deux mondes.

L'objectif n'est pas de choisir entre "client léger" ou "client lourd", mais plutôt de commenter les différentes solutions de client riche qui se mettent aujourd'hui en place.

[ludosoft]

Qu'est-ce que tu entends par peer-to-peer? Une architecture avec un serveur central de coordination et des postes clients qui font aussi office de serveur de données? On sort un peu de la discussion client riche là...

Connaissez-vous une solution équivalente à Java Web Start proposée par d'autres éditeurs ou est-ce que Java Web Start est le seul sur le marché à fournir ce processus de déploiement d'une application?

Oui effectivement c'est un peu en marge de la discussion. Mais quand même ; pour moi l'une des faiblesses des « plateformes de RIA » c'est le fait qu'il est très difficile de faire remonter des événements du serveur vers le client. Et à ma connaissance aujourd'hui il n'y a pas de méthode propre pour le faire. On passe soit par des connexions permanentes (ex : un chat en Flash ou en Java), soit par des requêtes régulières du client (ex : chat en HTML/JS). Sans avoir d'exemple sous la main, il est assez aisé d'imaginer une application critique qui aurait besoin d'être avertie d'événements survenus côté serveur de manière asynchrone.
Si on avait cette fonctionnalité je pense que la partie visible de la RIA, à savoir ce qu'on voit sur le navigateur, aurait plus de facilité à n'être qu'un périphérique d'affichage de l'appli et n'aurait pas besoin d'emparquer trop d'intelligence.

Après reste à trancher pour savoir qui d'entre le serveur et le client, doit être le plus intelligent. Et c'est là, qu'on verra ressortir la technologie qui a plus d'avenir. Entre celle qui déporte la couche de présentation et métier sur le client (avec tous les problèmes que cela comporte) et celle qui se contente de déléguer l'affichage de l'interface utilisateur, il y a un choix clair à faire. Reste à savoir laquelle le fera le mieux (entre problèmes de sécurité, de déploiement, d'ergonomie et de facilité de développement..).

Heu pardon yphilogene... Par peer-to-peer j'entendais un modèle qui permette au serveur de parler à ses clients de sa propre initiative. Peer-to-peer n'était pas le meilleur terme à employer du coup

[berceker united]

Oui effectivement c'est un peu en marge de la discussion. Mais quand même ; pour moi l'une des faiblesses des « plateformes de RIA » c'est le fait qu'il est très difficile de faire remonter des événements du serveur vers le client. Et à ma connaissance aujourd'hui il n'y a pas de méthode propre pour le faire. On passe soit par des connexions permanentes (ex : un chat en Flash ou en Java), soit par des requêtes régulières du client (ex : chat en HTML/JS). Sans avoir d'exemple sous la main, il est assez aisé d'imaginer une application critique qui aurait besoin d'être avertie d'événements survenus côté serveur de manière asynchrone.
Si on avait cette fonctionnalité je pense que la partie visible de la RIA, à savoir ce qu'on voit sur le navigateur, aurait plus de facilité à n'être qu'un périphérique d'affichage de l'appli et n'aurait pas besoin d'emparquer trop d'intelligence.

Après reste à trancher pour savoir qui d'entre le serveur et le client, doit être le plus intelligent. Et c'est là, qu'on verra ressortir la technologie qui a plus d'avenir. Entre celle qui déporte la couche de présentation et métier sur le client (avec tous les problèmes que cela comporte) et celle qui se contente de déléguer l'affichage de l'interface utilisateur, il y a un choix clair à faire. Reste à savoir laquelle le fera le mieux (entre problèmes de sécurité, de déploiement, d'ergonomie et de facilité de développement..).

Heu pardon yphilogene... Par peer-to-peer j'entendais un modèle qui permette au serveur de parler à ses clients de sa propre initiative. Peer-to-peer n'était pas le meilleur terme à employer du coup

Je pense que tu as mis le doigt dessus. Qui du client du serveur devra être intélligent. Jusqu'a présent tous le monde souhaite que ça soit le serveur car le service informatique voudrait avoir la maitrise.
Je pense qu'il faut pas que le client puisse être intelligent au risque que ça puisse se retourner contre le serveur point de vue sécurité.