Bonjour à tous,
Ce qui suit n'est que l'élucubration d'un esprit sans doute un peu tourmenté. Il s'agit d'une réflexion somme toute personnelle et d'une demande d'avis. J'espère que cela en intéressera quelques-uns et vais m'efforcer de ne pas être trop long.
Le tendance est au Web, et au développement autour des technologies Web. Enfonçons des portes très mal fermées car je concède aisément qu'il y a des atouts certains à cette mode :
- le client sensé universel, ou la joie de ne pas avoir à déployer et mettre à jour l'application chez le client
- un développement qui suit de plus en plus fréquemment des normes ouvertes
- un système décentralisé par défaut
- des échanges sensés simples : liens hypertexte, messages à base de XML / JSON et j'en passe
- ...
Mais on oublie parfois d'appuyer sur les défauts inhérents :
- les comportements des navigateurs qui diffèrent (moteurs JS et langage en lui même, rendus CSS, implémentations des normes en devenir ou existantes (1, 2...) qui obligent bien fréquemment à recourir à d'imposants morceaux de code clients, les frameworks.
- une certaine inertie due au consensus, ou comment les normes ont du mal à mener l'innovation et essaient davantage de rattraper leur retard
- des protocoles qui ne furent pas pensés pour concevoir des applications à part entière et ne me paraissent donc pas les plus appropriés, loin de là
- l'hétérogénéité des technologies (langage serveur, langage client imposé, (X)HTML, CSS, SVG, ...)
- le soucis de la vie privée, des données
- le bon fonctionnement lorsque la connectivité est rompue (et la synchronisation sensée en découler)
Mais le fait est qu'entre l'arrivée du HTML5, l'apparition de kits de composants Javascript toujours plus évolués (Sencha Ext, Qooxdoo et d'autres), le mouvement de l'informatique dans les nuages et ceux qui trouvent dans ce type de développement la manière de réaliser des applications visant plusieurs OS mobiles simultanément, le mouvement ne semble qu'en phase de décollage. On voit en effet de plus en plus fréquemment apparaitre des solutions complexes fonctionnant exclusivement en mode Web, par exemple des progiciels de gestion intégrée.
Il y a quelques années, les conséquences des défauts cités ci-dessus paraissaient plus clairs à l'utilisateur final : rendu parfois aléatoire des applications, réactivité faible, impression de lourdeur... Mais les performances des moteurs de rendu qui ont fortement crû, un matériel neuf devenu largement suffisant et les quelques évolutions des normes ont sans doute inversé cette tendance.
J'ai l'impression, peut-être fausse, que les moules (ou autres animaux dont la femelle est dotée de mamelles) qui liront ces lignes ont bien conscience de ces problématiques et une propension plus forte à résister à ce mouvement. Je me demande tout de même si le combat n'est pas déjà d'arrière-garde et s'il est encore possible aujourd'hui de concevoir de nouveaux outils en dehors du carcan du Web.
Car même dans des secteurs traditionnellement tournés vers le client lourd, le quidam me parait s'en aller. Je pense notamment à l'échange entre amis de films de vacances et de distributions (streaming en ligne, plateformes de téléchargement telle que MegaChargement), à l'écoute musicale (Dixheures) ou encore au visionnage de gens dévêtus (OléoléTube). Je pense qu'il en va de même pour les autres grands protocoles d'Internet (POP3/IMAP, NNTP, IRC...). Le village d'irréductibles se situe peut être du côté des jeux vidéo, même si je pense - à tort ? - que les joueurs occasionnels ont depuis longtemps opté pour la chose qui clignote dans le navigateur.. jusqu'à grignoter dans les joueurs assidus ?
Croyez-vous, chers lecteurs, qu'il y ait encore de la place pour des programmes destinés aux utilisateurs finaux, fonctionnant sur le grand Ternet (et non le Web), mais ne se souhaitant pas emprunter les chemins du butineur ?
Je songe à quelques pistes et veux bien votre sentiment :
- l'emploi de greffons à navigateurs de type machine virtuelle (Flash etc) ou encore l'exécution via Native Client;
- l'emploi d'une plateforme cliente reprenant l'architecture du Web et recevant ses informations (UI, rendu, données) depuis une machine distante;
- une plateforme all inclusive sur le principe du pair à pair où tout utilisateur serait à la fois client et serveur.
Suis-je un vieux réac qui refuse la modernité et ne voit pas toutes les opportunités offertes par Javascript-NG, HTML-NG et WebGL-NG ? Je trouve dommage de devoir se limiter à cette plateforme universelle qu'est devenue le navigateur Web dès que l'on vise le grand public, sauf à avoir une fonctionnalité de la mort. Car cela équivaut généralement à se passer d'autres types d'architectures, parfois plus adaptées, comme le pair à pair, ou tout simplement à ne pas employer des langages et bibliothèques non présents par défaut dans les navigateurs Web.
Merci de votre attention, pardonnez le délire du vieil homme.
# Remercie le mobile
Posté par Moogle . Évalué à 8.
Avec l'avènement du smartphone et des tablettes, la tendance est à faire tout plein d'applis "lourdes" (si on peut appeler lourde une appli mobile) pour remplacer les sites web. Ce qui donne l'occasion aux développeurs de faire plein de programmation non web.
Ça ne risque pas de grignoter la montée en puissance du web (ou éventuellement juste les portages de site en version light pour navigateurs mobiles), par contre c'est une alternative au développement tout web.
[^] # Re: Remercie le mobile
Posté par gUI (Mastodon) . Évalué à 10.
iOS a lancé le mouvement, c'est indéniable. Mais maintenant que Android arrive en force, c'est pas dit que ça dure...
Actuellement, il y a 2 grands OS mobiles qui regroupent X% de part de marché (flemme de chercher). Bcp d'applis se doivent d'être en double (je pense aux banques par exemple, ou un site web adapté au mobile est aussi ergonomique qu'une appli dédiée pour consulter 3 lignes de compte). Le jour où un 3e arrive (entre Meego et BlackBerry, il se pourrait qu'il y en ait un vraiment populaire) ça va commencer à devenir lourd.
Donc le retour au "putain le web c'est génial, même pas besoin de développer pour 3 OS différents", je le pronostique pour bientôt !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Remercie le mobile
Posté par lolop (site web personnel) . Évalué à 3.
Meego et BlackBerry feront une couche de compatibilité Androïd, et zoum.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Remercie le mobile
Posté par netsurfeur . Évalué à 7.
C'et déjà le cas: Alien Dalvik
Ils ont une démo avec des applications Android sur Meego.
[^] # Re: Remercie le mobile
Posté par lolop (site web personnel) . Évalué à 3.
Je sais, reste à trouver l'équivalent pour BlackBerry.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Remercie le mobile
Posté par netsurfeur . Évalué à 3.
Il semblerait que RIM y travaille.
Rien d'officiel, mais des rumeurs : http://www.gadgetell.com/tech/comment/rim-apparently-testing-android-apps-on-blackberry/
[^] # Re: Remercie le mobile
Posté par Misc (site web personnel) . Évalué à 2.
Et à trouver aussi un mobile avec meegoo :/
[^] # Re: Remercie le mobile
Posté par barmic . Évalué à 3.
Non, JME montreras sa vrai force.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Remercie le mobile
Posté par Grunt . Évalué à 9.
Oui, mais le problème c'est qu'on se retrouve avec une appli par couple plateforme/service. Ça fait beaucoup d'applis (donc, de temps perdu).
À l'âge d'or d'Internet (avant qu'il ne grouille de pompes à fric, quoi), il y avait un protocole pour un type de service (exemple: IRC), des applications qui géraient ce protocole pour chaque plateforme, et quand on voulait monter un service d'un certain type on utilisait le protocole qui va bien et on filait les informations de connexions.
Maintenant, c'est fini ça: le moindre service de chat va te proposer son "appli qui va bien", que tu es prié d'installer sinon ça ne marche pas, faute d'utilisation d'un protocole standard.
Pourtant, on sait même faire de l'authentification sur la plupart des protocoles.
Tiens, et si LinuxFR passait à NNTP pour diffuser les dépêches/journaux/demandes de forum + les commentaires? Au lieu de passer par.. un site Web :D
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Remercie le mobile
Posté par Juke (site web personnel) . Évalué à 5.
Le mardi 08 mars 2011 à 19:13 +0100, Grunt a écrit :
il y avais un acces nntp dans le passé, je ne sais pas ce qu'il est actuellement.
Par contre tu peux lire/repondre via ton client mail grace à monboob (https://symlink.me/projects/weboob/wiki/Monboob)
[^] # Re: Remercie le mobile
Posté par pasScott pasForstall . Évalué à 3.
Ou pas. Ce qu'il se passe la plupart du temps, c'est que les sites webs exposent une API REST en plus de leur API HTML (si j'ose dire). Sur un site decemment concu, ton code metier est package dans une lib, et apres tu construit 2 applis par dessus, une qui expose en REST, l'autre qui expose des pages HTML. Voire parfois, l'appli HTML se contente de faire des appels ajax a l'appli REST, donc l'un dans l'autre....
Le truc c'est que HTML n'a jamais ete un "protocole", c'est une technologie de presentation, ca se limite a ca.
C'est foutrement pratique, ca nous a bien depanne pendant 10 ans parce qu'on avait que ca a se mettre sous la dent, mais maintenant qu'on a des frameworks reellement riches decents et largement diffuses (ios/android), ben les sites s'en servent. Sont pas fous, ca fait des annees qu'ils revent de pouvoir faire des interfaces plus riche avec la souplesse de development web.
Au final, ton appli iOS/Android, c'est surtout une coquille vide qui fait des appels REST/JSON (tout ce qu'il ya de plus standard donc). Tu dois probablement pouvoir t'amuser a sniffer les paquets reseaux et voir ce qu'il passe, une API rest ca a rien de bien compliquer a reverse engineerer.
Ca fait certes du boulot en plus du site web, mais ca permet aussi de faire une application beaucoup plus agreable pour l'utilisateur. Pour reprendre l'exemple donne plus haut du compte en banque avec 3 lignes, j'ai pas forcement envie de me taper les grosses pages bien lourdes et blindees de pubs de ma banque pour verifier que mon flexi felix a bien ete debite. Pour d'autres cas d'utilisation plus pousse, je vais aller sur le site web, mais pour 90% de mes consultations, une simple appli toute bete suffira.
Au final, on reste sur le modele client leger/serveur lourd de ces 10 dernieres annees, on change juste la techno de presentation.
Rien de neuf sous le soleil.
Apres, pour la partie 1 service = 1 protocole.
Regarde ce que font la plupart des applis mobile. Pour l'immense majorite, c'est du read, avec eventuellement un peu de create, parfois du update/delete. Un bon vieux CRUD des familles quoi.
Regarde ce que fait REST avec GET tu implementes 95% de ton appli, PUT/POST/DELETE les 5% qui reste.
T'es libre de reinventer un protocole de communication si tu veux, mais HTTP marche foutrement bien, il est foutrement bien supporte, documente, tout le monde le connait et son seul gros probleme c'est d'etre stateless. Mais c'est sa grande forces (maintenir une connection, c'est pas simple), et le probleme de la session a ete resolue ya facile 20 ans.
Va falloir faire un sacre boulot pour le concurrencer serieusement, a commencer par ajouter le support de ton super protocole a tous les serveurs web/d'applis du marche.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Remercie le mobile
Posté par xumelc . Évalué à 2.
MAIS OUI !
[^] # Re: Remercie le mobile
Posté par Juke (site web personnel) . Évalué à 2.
Le mercredi 09 mars 2011 à 12:05 +0100, Clément Schreiner a écrit :
D'ailleurs y'a t'il une api pour la nouvelle version de linuxfr ?
[^] # Re: Remercie le mobile
Posté par pasScott pasForstall . Évalué à -3.
gne?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Remercie le mobile
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -1.
Aujourd'hui, monter un service de messagerie instantanée basé sur autre chose qu'XMPP, j'appelle ça de la connerie.
[^] # Re: Remercie le mobile
Posté par William Steve Applegate (site web personnel) . Évalué à 1.
Ah ? Moi, j'appelle ça « Facebook ».
[Pour être clair : oui, c'est stupide si on pense en tant que technicien voulant des protocoles ouverts et un réseau universellement accessible, mais je crains que les dAISSideurs devant leurs camemberts préfèrent nettement avoir des utilisateurs captifs monétisables à souhait...]
Envoyé depuis mon PDP 11/70
[^] # Re: Remercie le mobile
Posté par Moogle . Évalué à 4.
Facebook utilise Jabber pour l'accès à sa messagerie instantanée.
[^] # Re: Remercie le mobile
Posté par Misc (site web personnel) . Évalué à 4.
En théorie, on dit "xmpp", car jabber est une marque déposé ( iirc ), et xmpp désigne le protocole ( alors que jabber désigne un peu ce qu'on veut ).
[^] # Re: Remercie le mobile
Posté par Guillaume Knispel . Évalué à 8.
c'est même pire que ça: les services sont dorénavant ultra centralisés (au sens de qui les contrôles, ils peuvent très bien être par ailleurs hébergés en utilisant des techno assez distribuée), le minitel 2.0 a tué internet... :/
par exemple "facebook" créé il y a 15/20 ans (à l'époque ou tous les tecos voulaient faire avancer internet et non pas simplement faire leur petit minitel 2.0 dans leur coin pour devenir riche et célèbre) aurait débouché sur une RFC aux multiples implémentations et au final un contrôle naturel plus fin des données perso par les individuels via les programmes qu'ils utilisent (et peuvent contrôler grâce aux logiciels libres). facebook créé il y a ~ 5 ans a juste débouché sur la fortune/puissance/contrôle de quelques personnes, ôtant simultanément un pan de la vie privée des utilisateurs pour nourrir cette fortune (qui n'ont que le choix entre accepter une telle perte de contrôle sur leurs informations et la non utilisation de facebook, ce dernier ayant su se rendre incontournable pour certains en générant un cercle vicieux inhérent au service proposé)
[^] # Re: Remercie le mobile
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 3.
Ça a existé dans le temps, je crois, mais je ne l'ai jamais utilisé. Oh, il en reste une trace (au moins sur news://news.free.fr) : le groupe s'appelle
linuxfr.linuxfr-newset je viens d'y plopper. Reste à savoir si c'est correctement propagé.Usenet, c'est bien.
[^] # Re: Remercie le mobile
Posté par PetitCodeur . Évalué à 2.
Justement avec la fragmentation des OS pour smartphones et tablettes tactiles, sauf cas particuliers, il est plus intéressant de développer une version HTML5/CSS3/JS qui marchera partout. (enfin optimisé pour webkit).
D'autant plus que Steve peut pas te censurer ton appli en te raquetant des droits de passages et puis c'est normalisé par le W3C donc standard.
Les applis natives sont réellement nécessaires uniquement si t'as besoin de perfs ou d'utiliser des fonctionnalités non disponibles dans le browser.
[^] # Re: Remercie le mobile
Posté par Gabin . Évalué à 6.
D'autant plus que Steve peut pas te censurer ton appli en te raquetant des droits de passages.
Ouais mais ton Steve on lui doit sa fermeté envers Flash :). Certes, non pas pour les raisons qu'on voudrait mais c'est toujours ça de pris!
Si Flash avait été dispo sur les produits mobiles de la pomme, je pense que les adeptes du triptyque HTML5/CSS3/JS pourraient se la mordre longtemps.
[^] # Re: Remercie le mobile
Posté par Moogle . Évalué à 3.
Tous les commentaires ci-dessus font un peu le même constat sur la fragmentation. Mais à l'heure actuelle, avoir une appli pour son iPhone/Android, c'est "hype". Même si la plupart du temps ça n'est qu'un lecteur de flux RSS avec la skin qui va bien. Les gens sont assez demandeurs de l'appli jolie qui va bouffer son petit méga sur le téléphone, plutôt que le site mobile qui marche partout, et quasiment tous les gros sites se lancent dedans (à quand l'appli Linuxfr ?).
Je trouve ça très con aussi surtout que la plupart du temps, ces applis n'apportent rien. Mais tant que l'offre et la demande continueront à aller dans ce sens, on en verra encore beaucoup. D'autant plus que le problème de la fragmentation se résoudra vite avec l'arrivée de machines virtuelles Dalvik sur BlackBerry ou Bada. Comme ça, plus besoin que de deux versions : iOS et Android.
Et puis, réaliser une boîte à meuh qui utilise l'accéléromètre du téléphone en web, c'est pas encore trop possible.
# moules ?
Posté par Vador Dark (site web personnel) . Évalué à 9.
J'ai l'impression, peut-être fausse, que les moules (ou autres animaux dont la femelle est dotée de mamelles)
Je ne sais pas de quelle moule tu parles. Mais chez moi, la femelle de la moule (c'est à dire la moule), n'a pas de mamelle. Si tu parles des moules présentent ici, ils n'ont eux tout simplement pas de femelle (c'est pour ça qu'ils sont ici d'ailleurs).
[^] # Re: moules ?
Posté par Davy Defaud . Évalué à 8.
En effet, si une moule avait une femelle, ladite femelle aurait alors deux moules ; or, une femelle ne peut avoir deux moules. Par conséquent, une moule ne peut avoir de femelle. C.Q.F.D. !
# desktop 2.0
Posté par fredix . Évalué à 2.
J'avais écris un article sur le sujet desktop 2.0
Je fais parti de ceux qui ont en marre des web app, que ce soit comme utilisateur que comme développeur.
Le problème est que les applications desktop n'ont pas évoluées depuis 30 ans. Presque aucune ne propose des fonctionnalités exploitant Internet, comme la synchro des datas, la communication avec d'autres utilisateurs via Internet etc. Or le web a lui rapidement évolué avec l'avènement des API et du social...
Il existe enfin des solutions comme social desktop et desktopcouch mais ça arrive un peu tard... La faute aux framework de bureau, car GNOME et KDE n'ont rien proposé pour faciliter l'exploitation d'Internet via des API. Pour cela il faudrait-il encore qu'ils proposent des services type Jabber, email, etc, afin de faciliter l'adoption des outils natifs par les utilisateurs et simplifier le développement...
[^] # Re: desktop 2.0
Posté par Grunt . Évalué à 5. Dernière modification le 09 mars 2011 à 11:57.
Les applications desktop n'ont pas eu besoin d'évoluer pour proposer, depuis longtemps, la synchro des datas (grsync), la communication entre utilisateurs (Jabber) et autres fonctions qu'on fait semblant de découvrir aujourd'hui.
Le problème se trouve dans la volonté de contrôle des éditeurs de services propriétaires, et dans l'ignorance de la majorité des internautes (le fait qu'Internet soit grand public a simplement dilué les geeks).
Ce qui fait que la moindre fonction basique (synchro, communication entre utilisateurs) est considérée comme une évolution majeure alors qu'elle existe depuis 20 ans.
Et le web n'a pas vraiment évolué.. ça reste basé sur du HTTP sur lequel on empile des couches pour pallier ses insuffisances.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: desktop 2.0
Posté par fredix . Évalué à -1.
Tu cites des applications alors que je parles d'API de synchronisation et de chat proposés par un framework desktop et utilisant des services libres mais pas forcément gratuit, fournis par les diverses fondation et entreprises du libre. Ainsi n'importe quel développeur pourrait intégrer facilement XMPP dans son application, la synchro, etc, et l'utilisateur pourrait en bénéficier immédiatement. Ca change un peu tout...
La différence est que le web est passé d'un modèle vertical, présenter des pages, à un modèle horizontal, faire communiquer des applications grâce à des techniques comme les webhook, pubsubhubbub, les API REST, etc. Or le desktop reste sur un modèle vertical, une activité un logiciel. Il est complètement archaique que chaque développeur doit implémenter les protocoles de communication et de synchronisation dans son application. Finalement en 2011 les applications natives desktop ne le font toujours pas et fonctionnent sans exploiter les capacités d'Internet.
[^] # Re: desktop 2.0
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
la communication entre utilisateurs (Jabber)
Jabber promettait de révolutionner les communications. En pratique il n'y a que le chat en texte basique qui marche bien...
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: desktop 2.0
Posté par neerd . Évalué à 3.
Fallait mettre une pomme dessus:
"Ceci est une révolution"
[^] # Re: desktop 2.0
Posté par Gabin . Évalué à 0.
Jabber promettait de révolutionner les communications. En pratique il n'y a que le chat en texte basique qui marche bien...
Mon googletalk/gmail a l'air de faire plus de chose...
# La "vraie" vie
Posté par jigso . Évalué à 2.
La "vraie" vie, à l'ancienne, sera de toute façon coté serveur. On a tout à gagner à passer "sur le web" : la couche de présentation est éjectée des trucs vraiment intéressant, cad du coté "métier" de l'application. Reste donc coté serveur les bases de données SQL/NoSQL/whatever, les services de traitements, les connections avec les autres applis via des protocoles d'hommes (SMTP/POP/IMAP/LDAP/NNTP/IRC/...), on peut utiliser tous les langages de la création, et toutes les archis possibles, et on n'est plus embêter par les contraintes du client graphiques (genre windows only).
Finalement rien de change en profondeur...
[^] # Re: La "vraie" vie
Posté par Batchyx . Évalué à 4.
Tu n'est peut être plus embêté par les contraintes du client graphique, mais tu est quand même lourdement embêté par les contraintes du réseau, ce qui est encore pire. Tu doit gérer le fait que ton réseau perde une connexion au pire moment possible, que le réseau soit coupé entre le moment ou le serveur à reçu une demande de modification et le moment ou il renvoie la réponse positive ... et ceci sans l'aide de l'utilisateur, puisque le bouton "reload" ne marche pas sur du javascript.
Et tu doit surtout gérer le fait de ne pas avoir de réseau du tout, et l'utilisateur veut avoir ses données quand même.
[^] # Re: La "vraie" vie
Posté par jigso . Évalué à 2.
Ce sont des contraintes qui existent de toute façon. Si tu considère un client lourd qui se connecte en direct à un base de données, tu auras exactement les même soucis : en cas de perte de réseau au milieu d'un traitement, comment gérer la reprise sur incident. C'est inhérent au fait qu'il y a un réseau entre un client et un serveur ; actuellement, beaucoup - pour ne pas dire la plupart - des softs sont des softs communicants, des applis complètement statiques sur un poste de travail style gimp ou *office ne forment plus le gros des développements, tout se passe en mode client/serveur (client dédié/protocol privé pour les applis style Iphone, client HTML+JS/HTTP pour le reste du monde libre, seule les technos varient, les concepts restent identiques).
[^] # Re: La "vraie" vie
Posté par Batchyx . Évalué à 2.
Un client lourd qui ne fait qu'accéder à une base de données ... j'appellerai plutôt ça un client léger. Ça sert effectivement à rien de recoder un client pour ça.
Pour moi le client lourd, c'est le client qui va télécharger le morceau de base de données qui nous intéresse (de manière transparente, ou à la main) pour y accéder en local, qui va avoir une fonction "tout synchroniser et passer en mode hors ligne/lecture seule/tiens regarde l'historique ilébo", qui permet de sauvegarder des morceaux dans un fichier à mettre sur une clef USB ou autre, et à échanger avec tout ses amis. Dans les cas simples, elle permet de préparer en local des modifications à faire sur la base de donnée.
Enfin bref, comme toutes les clients mails lourd, les messageries instantanées lourdes, les navigateurs lourds, les gestionnaires de versions lourds ...
# ça résiste encore
Posté par Adrien . Évalué à 6.
Il y a bien des domaines qui résiste encore : le p2p par exemple ! Il y a plein de client bittorrent en activité, le Usenet binaire a lui aussi beaucoup d'adepte… Skype résiste lui aussi plutot bien il me semble.
Les deux approches ont leurs avantages : par exemple on peut très bien avoir kmail ET le webmail roundcube (auto-hébergé bien sur…) en parallèle. Il y a parfois des choses critiquables, comme par exemple passer par un forum au lieu d'un serveur NNTP.
Perso je ne pense pas que les client lourd ou léger soient un problème, mais plutot la centralisation des choses. Il est évident que les applications web sont un régal pour tout ceux qui veulent centraliser tout et n'importe quoi : utiliser facebook au lieu des emails est un exemple remarquable.
# SAP !
Posté par Houbaa . Évalué à 8.
Vient faire du SAP ! Des technos du millénaire dernier ! Du bon ABAP et bon JAVA ringuard ! Du pseudo SQL ! Un client lourd avec plein de paramètres inmaîtrisables ! De la sécu comme on en faisait en 87 ! Des problématiques de déploiement insolubles ! Une ergonomie digne de la RDA !
Franchement, tu ne sais pas ce que tu manques. Le client lourd-serveur lourd, c'est l'avenir du passé.
[^] # Re: SAP !
Posté par palm123 (site web personnel) . Évalué à 4.
Je ne suis pas d'accord. Le client est pieds et poings, c'est super pour SAP, il a un client à vie.
Et dire qu'on dit du mal des fabricants de tabac...
Et puis, comme le PDG ne veut pas passer pour un con auprès de ses potes PDG en faisant son golf, il donne carte blanche au DSI pour déployer SAP. Comme le DSI veut sa rallonge, il va mettre les moyens, dépenser un fric fou, et SAP sera installé.
Ah un détail, avec le nouveau système, on a des résultats faux et beaucoup moins de détails dans le reporting, mais on s'en fout, on est modernes, on a SAP !
ウィズコロナ
[^] # Re: SAP !
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 5.
C'est ce qu'on appelle un travail de SAPe.
# un système décentralisé par défaut
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Le développement web n'est pas du tout décentralisé par défaut. C'est même plutôt le contraire qui est naturel : un serveur bien lourd et plein de clients légers.
C'est bien dommage d'ailleurs qu'ils n'existent pas une façon simple d'écrire des applications P2P, faciles installer, faciles à mettre à jour...
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.