Il y a un conflit d'intérêt évident entre les concepteurs des sites et les programmeurs de scripts.
C'est vrai, mais ce n'est pas une fatalité. Je serai prêt à payer un abonnement modique pour avoir accès à une bonne API. Cela devrait compenser par exemple les pertes de revenus liés à la publicité. De plus, fournir une information par une API coûte largement moins cher que de fournir un site complet.
Et je serai prêt à payer encore plus pour un module weboob maintenu par le site en question (et si les choses sont bien faites, le site pourrait ajouter un cache local permettant de diminuer le « coût » de weboob).
Le HTML a une caractéristique particulière, c'est qu'il impose un modèle "open source"
Je vois ce que tu veux dire. On a pu rencontrer du HTML bien pourri (notamment les sites de banques où il faut y aller de manière quasiment heuristique) et arriver à en faire quelque chose. Cependant le code JavaScript, surtout minifié, est une autre paire de manches.
la liberté de faire évoluer son site est fondamentale, on ne peut pas être prisonnier de ses visiteurs
Je n'ai rien contre leur liberté, mais je trouve justement étrange le peu d'attachement à la stabilité et la rétrocompatibilité des sites internet, alors que c'est beaucoup plus répandu dans le logiciel « lourd ». C'est d'ailleurs ce qui a poussé la création du système de mise à jour des modules dans Weboob. On est attachés à la stabilité des applications et de l'API (du moins dans une même version majeure), mais pour les modules on est obligés de s'aligner sur les sites.
[^] # Re: Bonnes pratiques vs liberté
Posté par laurentb . En réponse au journal APPEL POUR ACTION : LES BOOBS ONT BESOIN DE VOUS *MAINTENANT*. Évalué à 4.
C'est vrai, mais ce n'est pas une fatalité. Je serai prêt à payer un abonnement modique pour avoir accès à une bonne API. Cela devrait compenser par exemple les pertes de revenus liés à la publicité. De plus, fournir une information par une API coûte largement moins cher que de fournir un site complet.
Et je serai prêt à payer encore plus pour un module weboob maintenu par le site en question (et si les choses sont bien faites, le site pourrait ajouter un cache local permettant de diminuer le « coût » de weboob).
Je vois ce que tu veux dire. On a pu rencontrer du HTML bien pourri (notamment les sites de banques où il faut y aller de manière quasiment heuristique) et arriver à en faire quelque chose. Cependant le code JavaScript, surtout minifié, est une autre paire de manches.
Je n'ai rien contre leur liberté, mais je trouve justement étrange le peu d'attachement à la stabilité et la rétrocompatibilité des sites internet, alors que c'est beaucoup plus répandu dans le logiciel « lourd ». C'est d'ailleurs ce qui a poussé la création du système de mise à jour des modules dans Weboob. On est attachés à la stabilité des applications et de l'API (du moins dans une même version majeure), mais pour les modules on est obligés de s'aligner sur les sites.