Comme certains l'ont dit plus haut, l'avenir est à mon avis vers des applications desktop connectées à des services web qui permettent de synchroniser ses données. Et la version web lorsqu'on est en déplacement ... J'imagine même que des site web ne fourniront qu'une API sans interface web (clients desktop Air ou Java)...
La plupart des sites web "serieux" commecent à offrir des webservices de type REST vraiment bien foutu. Le meilleur exemple est Google Data. Tu peux attaquer l'API soit directement soit via leur lib cliente. En général y'a pas trop d'interet a recoder le client.
De ce coté ca évolue plutot dans le bon sens. On developpe des clients lourds de plus en plus facilement et on peut de plus en plus combiner les services (cf Yahoo pipe).
Pour aller dans ton sens le lancement cette semaine de http://wua.la/ . L'interet du site repose entièrement sur les services fournis. Quand est ce que les rabacheurs du Minitel 2.0 nous pondent un service équivalent libre ?
A noter aussi que Java 6u7 a introduit la modularisation du JRE/JDK (download des fonctionalités à la volée) et les applets v2 (maintenant une applet tourne dans une JVM séparée).
Le prochain défi du Libre sera à mon avis la capacité à proposer des services de type ceux de Google voir installable sur son propre serveur, ce qui résoudrait des problèmes de tenues en charge. Car seul une batterie d'experts ingénieurs dans divers domaines et des datacenters permettent d'y répondre, et il faut s'appeller Google ou Amazon pour se les payer. La preuve, Facebook rame, l'API lasfm rame, MugShot rame, etc etc.
T'as tout compris. Des mecs capables de faire des archis bien foutues et scalables c'est rare. En plus de la conception il te faut l'infrastructure et l'équipe opérationelle pour l'exploiter. De mémoire le cout d'exploitation de google/yahoo/amazon est entre 50 et 100 inférieur á celui d'une entreprise plus classique.
[^] # Re: Fusion
Posté par ckyl . En réponse au journal Applications web vs applications classiques: quid du futur ?. Évalué à 3.
La plupart des sites web "serieux" commecent à offrir des webservices de type REST vraiment bien foutu. Le meilleur exemple est Google Data. Tu peux attaquer l'API soit directement soit via leur lib cliente. En général y'a pas trop d'interet a recoder le client.
Une bonne présentation de GData est disponible ici: http://www.slideshare.net/deimos/frank-mantek-google-g-data
De ce coté ca évolue plutot dans le bon sens. On developpe des clients lourds de plus en plus facilement et on peut de plus en plus combiner les services (cf Yahoo pipe).
Pour aller dans ton sens le lancement cette semaine de http://wua.la/ . L'interet du site repose entièrement sur les services fournis. Quand est ce que les rabacheurs du Minitel 2.0 nous pondent un service équivalent libre ?
Enfin SUN avait développé l'énormissime Java web Start [http://fr.wikipedia.org/wiki/Java_Web_Start] et la libération complète de Java risque à mon avis de le relancer.
A noter aussi que Java 6u7 a introduit la modularisation du JRE/JDK (download des fonctionalités à la volée) et les applets v2 (maintenant une applet tourne dans une JVM séparée).
Le prochain défi du Libre sera à mon avis la capacité à proposer des services de type ceux de Google voir installable sur son propre serveur, ce qui résoudrait des problèmes de tenues en charge. Car seul une batterie d'experts ingénieurs dans divers domaines et des datacenters permettent d'y répondre, et il faut s'appeller Google ou Amazon pour se les payer. La preuve, Facebook rame, l'API lasfm rame, MugShot rame, etc etc.
T'as tout compris. Des mecs capables de faire des archis bien foutues et scalables c'est rare. En plus de la conception il te faut l'infrastructure et l'équipe opérationelle pour l'exploiter. De mémoire le cout d'exploitation de google/yahoo/amazon est entre 50 et 100 inférieur á celui d'une entreprise plus classique.
Bonne chance à ceux qui voudrait jouer :-)
Pour ceux qui veulent découvrir un peu le domaine, http://highscalability.com/ est un bon point d'entrée. Il y a aussi de bonne présentations la http://qconlondon.com:80/london-2008/tracks/show_track.jsp?t(...) et http://qconsf.com/sf2007/tracks/show_track.jsp?trackOID=70