mysql peut être utilisé sans lancer de serveur, directement depuis akonadi (ou toute autre appli) avec la libmysql et attaquer un fichier privé comme base de données.
"On pourrait effectivement parler de performances, de cache, mais pour ça, il faudrait que kde4 soit performant."
tu disais te poser cette question "très sérieusement" Que viens faire cette insulte gratuite qui n'apporte rien là dedans ?
1) les performances de kde sont moins bonnes que celles de kde3, mais elles ne sont pas "catastrophiques"
2) les problèmes de performances sur certains problèmes n'empêchent en rien le fait de vouloir les régler sur d'autres.
3) les optimisations de code et d'algo ne suffisent pas toujours à améliorer les performances, on fini par atteindre les limites de ce qui peut être fait à un moment, et si on veut faire mieux, la seule façon est d'essayer une autre voie.
"Et puis, monter une usine à gaz pour charger 300 contacts, je suis pas convaincu. Par contre, stocker chaque mail que je consulte via imap dans une base de données, je suis sûr que ça plombe les perfs."
akonadi, c'est pas pour stocker 300 contacts, je pense que même les développeurs KDE savent que pour ça, on a pas besoin d'un système de gestion des données personnelles centralisées qui utilise un SGBD.
Ensuite, tu as beau être "sûr que ça plombe les perfs" ça reste de la théorie de comptoire, et en matière d'optimisation, il n'y a qu'une seule règle absolue, tester !
Tu vas toujours trouver que dans ton super cas à toi avec 3 mail et 1 date dans ton calendrier, les perfs sont plombées, mais si ça prends 0.003 secondes au lieu de 0.000001 secondes, c'est pas la mort. Par contre, le type qui a vraiment une grosse base de mails, de contacts, de calendriers et tout, il sera content d'avoir un truc plus réactif.
De ton coté, si tu ne peux pas patienter ces 0.002999 secondes supplémentaires, tu peux toujours utilser mutt, il lira et fera des recherches dans tes 1 mail super rapidement et sans plomber aucune perf !
"Non, je crois vraiment qu'aknoadi est l'un des pires choix qu'ait fait kde4. Sur le papier, ça avait l'air joli, dans les faits, ça ne marche pas."
Moi j'appelle ça un bon choix, plombé par des problèmes techniques et des retards d'implémentation.
Je suis le premier frustré de l'avancement d'akonadi, j'aurai aimé (et je pensais, à la sortie de kde 4.0) en être au point actuel dans la version 4.2 de KDE, finalement, c'est beaucoup plus long que prévu, mais les choses avancent, et je ne doute toujours pas des avantages technologique de ce choix par rapport aux autres, comme je ne doutais pas du potentiel de kde 4 avant la sortie de la 4.0, et il n'y a qu'a voir la vitesse à laquelle les développeurs arrivent à faire avancer les choses à chaque version pour s'en convaincre. ça a été long, mais maintenant, chaque version, en plus d'ajouter son lot de régressions, viens avec ses améliorations en terme de performance et consomation, d'ergonomie, de fonctionnalités et de nouveau outils et logiciels.
[^] # Re: kdepim non inclu
Posté par moi1392 . En réponse à la dépêche Sortie de KDE 4.5. Évalué à 3.
"On pourrait effectivement parler de performances, de cache, mais pour ça, il faudrait que kde4 soit performant."
tu disais te poser cette question "très sérieusement" Que viens faire cette insulte gratuite qui n'apporte rien là dedans ?
1) les performances de kde sont moins bonnes que celles de kde3, mais elles ne sont pas "catastrophiques"
2) les problèmes de performances sur certains problèmes n'empêchent en rien le fait de vouloir les régler sur d'autres.
3) les optimisations de code et d'algo ne suffisent pas toujours à améliorer les performances, on fini par atteindre les limites de ce qui peut être fait à un moment, et si on veut faire mieux, la seule façon est d'essayer une autre voie.
"Et puis, monter une usine à gaz pour charger 300 contacts, je suis pas convaincu. Par contre, stocker chaque mail que je consulte via imap dans une base de données, je suis sûr que ça plombe les perfs."
akonadi, c'est pas pour stocker 300 contacts, je pense que même les développeurs KDE savent que pour ça, on a pas besoin d'un système de gestion des données personnelles centralisées qui utilise un SGBD.
Ensuite, tu as beau être "sûr que ça plombe les perfs" ça reste de la théorie de comptoire, et en matière d'optimisation, il n'y a qu'une seule règle absolue, tester !
Tu vas toujours trouver que dans ton super cas à toi avec 3 mail et 1 date dans ton calendrier, les perfs sont plombées, mais si ça prends 0.003 secondes au lieu de 0.000001 secondes, c'est pas la mort. Par contre, le type qui a vraiment une grosse base de mails, de contacts, de calendriers et tout, il sera content d'avoir un truc plus réactif.
De ton coté, si tu ne peux pas patienter ces 0.002999 secondes supplémentaires, tu peux toujours utilser mutt, il lira et fera des recherches dans tes 1 mail super rapidement et sans plomber aucune perf !
"Non, je crois vraiment qu'aknoadi est l'un des pires choix qu'ait fait kde4. Sur le papier, ça avait l'air joli, dans les faits, ça ne marche pas."
Moi j'appelle ça un bon choix, plombé par des problèmes techniques et des retards d'implémentation.
Je suis le premier frustré de l'avancement d'akonadi, j'aurai aimé (et je pensais, à la sortie de kde 4.0) en être au point actuel dans la version 4.2 de KDE, finalement, c'est beaucoup plus long que prévu, mais les choses avancent, et je ne doute toujours pas des avantages technologique de ce choix par rapport aux autres, comme je ne doutais pas du potentiel de kde 4 avant la sortie de la 4.0, et il n'y a qu'a voir la vitesse à laquelle les développeurs arrivent à faire avancer les choses à chaque version pour s'en convaincre. ça a été long, mais maintenant, chaque version, en plus d'ajouter son lot de régressions, viens avec ses améliorations en terme de performance et consomation, d'ergonomie, de fonctionnalités et de nouveau outils et logiciels.