Je n'ai écrit ni newsreader ni client RSS, mais si j'imagine un usage un peut intensif du client RSS, ca va me permettre de faire des corrélations entre sources mais aussi de proposer à l'utilisateur de chercher dedans de façon tres evoluée.
Pour un client mail je vois tout de suite l'usage, j'ai personnellement plus de 2Gb de mail (je ne jette rien depuis 1997) et j'ai écris mon propre petit outil d'indexation (avec SQLLite il se trouve) pour chercher dedans plus simplement qu'avec aucun client mail que je connaisse. Rien de bien tordu mais ca marche et vite (le fichier de reference fait environ 15Mb).
"Lire et écrire un fichier n'est pas particulièrement compliqué, "; Il n'y qu'a voir avec quelle régularité un bon nombre d'applis corrompent leurs données, ou deviennent incapable de relire leur formats de fichiers entre deux versions. Faire une paire de routines de lecture écriture de fichier n'est pas bien compliqué, mais définir un bon format de fichier, le faire vivre et évoluer, ca n'a rien de simple. La dessus ajoute le fait que pour debugguer le tout il faudra sans doute ecrire ses propres outils d'exploration, génération d'exemples, mise à jour ..... bref ca devient vite compliqué.
Bien sur avec un format pur texte c'est plus simple, à condition d'avoir pensé au départ au multilinguisme, et à encoder les données purement binaire (son, images, échantillions de mesures) avant de les écrire (et évidemment faire attention à l'encodage entre librairies : chaines UTF-XX, ASCII, 8859-xx ?).
Au final si tant de monde adopte le XML et les librairies de lecture/écriture de ce format ca n'est pas sans bonnes raisons.
Pour ce qui est des fonctions de tri, oui il y'en a partout, mais il faut a chaque fois recoder les fonctions de comparaison, c'est à mes yeux plus complexe (surtout à maintenir) qu'une syntaxe dédiée à cet usage telle celle du SQL. Sans compter que moult programmeurs préferent réimplementer leur propres fonctions plutot que tenter d'utiliser les fonctions évoluées des bibliothèques (voir l'usage de la librairie standard C++ hors du cercle des experts de la norme).
SQLLite fournit un stockage relationnel, et les outils qui vont avec, je vois peut de problèmes provoqués par cela (mais je ne vais pas essayer de faire rentrer dedans des données qui ne s'y pretent pas).
La news est un chouia enthousiaste, mais je m'y joins pour inviter chaque programmeur qui ne soit pas trop "à cheval" sur la GPL à jeter un oeil à SQLite parceque c'est bien fichu et vraiment à connaitre pour LA fois ou ce sera peut être la réponse au problème du jour.
[^] # Re: explosion du trokilometre
Posté par Christophe Renard . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 3.
Pour un client mail je vois tout de suite l'usage, j'ai personnellement plus de 2Gb de mail (je ne jette rien depuis 1997) et j'ai écris mon propre petit outil d'indexation (avec SQLLite il se trouve) pour chercher dedans plus simplement qu'avec aucun client mail que je connaisse. Rien de bien tordu mais ca marche et vite (le fichier de reference fait environ 15Mb).
"Lire et écrire un fichier n'est pas particulièrement compliqué, "; Il n'y qu'a voir avec quelle régularité un bon nombre d'applis corrompent leurs données, ou deviennent incapable de relire leur formats de fichiers entre deux versions. Faire une paire de routines de lecture écriture de fichier n'est pas bien compliqué, mais définir un bon format de fichier, le faire vivre et évoluer, ca n'a rien de simple. La dessus ajoute le fait que pour debugguer le tout il faudra sans doute ecrire ses propres outils d'exploration, génération d'exemples, mise à jour ..... bref ca devient vite compliqué.
Bien sur avec un format pur texte c'est plus simple, à condition d'avoir pensé au départ au multilinguisme, et à encoder les données purement binaire (son, images, échantillions de mesures) avant de les écrire (et évidemment faire attention à l'encodage entre librairies : chaines UTF-XX, ASCII, 8859-xx ?).
Au final si tant de monde adopte le XML et les librairies de lecture/écriture de ce format ca n'est pas sans bonnes raisons.
Pour ce qui est des fonctions de tri, oui il y'en a partout, mais il faut a chaque fois recoder les fonctions de comparaison, c'est à mes yeux plus complexe (surtout à maintenir) qu'une syntaxe dédiée à cet usage telle celle du SQL. Sans compter que moult programmeurs préferent réimplementer leur propres fonctions plutot que tenter d'utiliser les fonctions évoluées des bibliothèques (voir l'usage de la librairie standard C++ hors du cercle des experts de la norme).
SQLLite fournit un stockage relationnel, et les outils qui vont avec, je vois peut de problèmes provoqués par cela (mais je ne vais pas essayer de faire rentrer dedans des données qui ne s'y pretent pas).
La news est un chouia enthousiaste, mais je m'y joins pour inviter chaque programmeur qui ne soit pas trop "à cheval" sur la GPL à jeter un oeil à SQLite parceque c'est bien fichu et vraiment à connaitre pour LA fois ou ce sera peut être la réponse au problème du jour.