ok, je me suis peut-être mal exprimé, mais il me semblait en avoir parler. l'intérêt du serveur plutôt qu'une api ou chaque appli attaque les fichiers de config dans son propre process est la gestion des accès concurrents (sur du nfs par exemple, c'est impossible à faire, sur un FS local, ça l'est, mais c'est très compliqué et limité), la gestion plus fine des droits (rien dans akonadi ne permet à l'heure actuelle de faire ça, mais c'est complètement infaisable avec un accès direct aux données depuis les applications) et la gestion de caches et des ressources et leur réutilisation par plusieurs applis (performances améliorées, pas besoin de reparser les fichiers de données et config pour chaque appli, pas besoin de se connecter au serveur imap pour chaque appli)
Pour DBus sur le réseau, il me semble que ça a toujours fonctionné, il y a de sévères limitations (entre autre l'impossibilité d'identifier avec certitude l'id de l'utilisateur faisant la requête, ce qui parait normal, et aussi des problèmes de performance) mais DBus en lui même dialogue par dessus une socket de type unix, qui a strictement (à part pour l'id utilisateur donc) la même api et le même fonctionnement qu'une socket tcp. Et il me semble que le code qui ouvre la socket en TCP au lieu d'UNIX est déjà dans DBus depuis la 1.0
[^] # Re: kdepim non inclu
Posté par moi1392 . En réponse à la dépêche Sortie de KDE 4.5. Évalué à 1.
Pour DBus sur le réseau, il me semble que ça a toujours fonctionné, il y a de sévères limitations (entre autre l'impossibilité d'identifier avec certitude l'id de l'utilisateur faisant la requête, ce qui parait normal, et aussi des problèmes de performance) mais DBus en lui même dialogue par dessus une socket de type unix, qui a strictement (à part pour l'id utilisateur donc) la même api et le même fonctionnement qu'une socket tcp. Et il me semble que le code qui ouvre la socket en TCP au lieu d'UNIX est déjà dans DBus depuis la 1.0