Apparemment SQLite est récent. Qqun peut me dire pourquoi ils ont réimplémenté eux-mêmes toutes les fonctions de stockage (hash, arbres, transactions...) alors qu'il suffisait d'écrire un frontend SQL à Berkeley DB 4 qui gère déjà très bien (et depuis longtemps) tout le "sale boulot'" ?
D'ailleurs, je serais curieux de voir ce que pourrait donner la comparaison SQLite vs {BerkeleyDB + frontend SQL "bien écrit"} niveau benchmarks... ça au moins ce serait comparable (contrairement à du "SQlite vs MySQL" de base, qui est un peu absurde vu que MySQL est un serveur !).
N.B.: J'ai vu que MySQL disposait aussi d'un mode "bibliothèque", dans lequel on peut se passer de serveur (MySQL devient simplement une bibliothèque à linker, comme SQLite). Si on veut comparer les performances entre les 2 il faut utiliser MySQL de cette façons... Qqun sait ce que ça donne ?
Pourquoi se borner aux deux seules solutions :
- soit on continue dans la voie actuelle (protocole X bas niveau + toolkits (GTK/QT) gourmands)
- soit on recommence tout à zéro (Fresco/Y)
=> On pourrait très bien imaginer d'étendre le protocole X (de même qu'il existe plein d'autres extensions comme Render, etc...) avec des appels de haut niveau (à la GTK) pour gérer le rendu du toolkit côté serveur ! (et si ça a du succès QT et GTK pourraient en partie être réécrits pour n'être que des "wrappers" autour de cette extension).
Il me semble que ce genre de solution résoudrait le problème sans casser la compatibilité ou tout recommencer à 0 puisque les deux "modes" seraient possibles. (dites moi si je me trompe)
Autre chose tant que j'y suis : je trouve que ça pourrait être pas mal si on séparait aussi (côté serveur) nettement la partie "driver graphique" de la partie "serveur", de manière à avoir une bibliothèque "à la SDL" qui parle directement au hardware sans avoir à se taper des couches intermédiaires (comme X, puisque actuellement il me semble que SDL est au dessus de X et non en dessous, le contraire serait plus logique non ?), ça serait pratique pour les jeux et ça rendrait le serveur X plus modulaire.
(je sais, SDL existe au dessus du framebuffer mais dans ce cas on pert tous les bénéfices des drivers graphiques accélérés de X, idem dans le cas de DirectFB où les drivers sont réécrits en partants de 0).
Bon, je sais, << les "y'a qu'à" et les "faut qu'on" sont les prédateurs de l'homo bénévolus >>, mais vu l'ampleur c'est pas vraiment le genre de truc qu'on peut expérimenter tout seul dans son coin... ;)
# BerkeleyDB ?
Posté par karteum59 (site web personnel) . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 4.
D'ailleurs, je serais curieux de voir ce que pourrait donner la comparaison SQLite vs {BerkeleyDB + frontend SQL "bien écrit"} niveau benchmarks... ça au moins ce serait comparable (contrairement à du "SQlite vs MySQL" de base, qui est un peu absurde vu que MySQL est un serveur !).
N.B.: J'ai vu que MySQL disposait aussi d'un mode "bibliothèque", dans lequel on peut se passer de serveur (MySQL devient simplement une bibliothèque à linker, comme SQLite). Si on veut comparer les performances entre les 2 il faut utiliser MySQL de cette façons... Qqun sait ce que ça donne ?
[^] # Re: Long coup de gueule
Posté par karteum59 (site web personnel) . En réponse à la dépêche Traduction en français du "Encourage Women in Linux HOWTO". Évalué à 4.
Bon OK je sors... -> []
[^] # Re: Mouais
Posté par karteum59 (site web personnel) . En réponse à la dépêche Traduction en français du "Encourage Women in Linux HOWTO". Évalué à 6.
Au fait, comment il faut appeler une femme chasseur alpin ? :o)
[^] # Re: Y.org
Posté par karteum59 (site web personnel) . En réponse à la dépêche XFree86 a de moins en moins la côte. Évalué à 1.
- soit on continue dans la voie actuelle (protocole X bas niveau + toolkits (GTK/QT) gourmands)
- soit on recommence tout à zéro (Fresco/Y)
=> On pourrait très bien imaginer d'étendre le protocole X (de même qu'il existe plein d'autres extensions comme Render, etc...) avec des appels de haut niveau (à la GTK) pour gérer le rendu du toolkit côté serveur ! (et si ça a du succès QT et GTK pourraient en partie être réécrits pour n'être que des "wrappers" autour de cette extension).
Il me semble que ce genre de solution résoudrait le problème sans casser la compatibilité ou tout recommencer à 0 puisque les deux "modes" seraient possibles. (dites moi si je me trompe)
Autre chose tant que j'y suis : je trouve que ça pourrait être pas mal si on séparait aussi (côté serveur) nettement la partie "driver graphique" de la partie "serveur", de manière à avoir une bibliothèque "à la SDL" qui parle directement au hardware sans avoir à se taper des couches intermédiaires (comme X, puisque actuellement il me semble que SDL est au dessus de X et non en dessous, le contraire serait plus logique non ?), ça serait pratique pour les jeux et ça rendrait le serveur X plus modulaire.
(je sais, SDL existe au dessus du framebuffer mais dans ce cas on pert tous les bénéfices des drivers graphiques accélérés de X, idem dans le cas de DirectFB où les drivers sont réécrits en partants de 0).
Bon, je sais, << les "y'a qu'à" et les "faut qu'on" sont les prédateurs de l'homo bénévolus >>, mais vu l'ampleur c'est pas vraiment le genre de truc qu'on peut expérimenter tout seul dans son coin... ;)