Tu parles d'efficacité du point de vue management du projet et de ses évolutions futures, ou de l'efficacité en termes de rapidité d'affichage ? (En quoi la rapidité de l'affichage dépend-elle de savoir si la fonctionnalité est intégrée dans Wayland ou dans Weston ?)
Wayland vise à être performant et donc soit il se concentre sur l'affichage locale, soit il fait comme X et a des protocoles pour le local (DRI) et d'autres pour le distant. Mais vu que Wayland vise aussi à être maintenable, il ne veut prendre en charge différents protocole (vu que c'est une des raisons qui fait que X n'est plus maintenable).
Évidemment, si tu trouve un protocole qui rivalise à la fois avec tous les protocoles distants et locaux, tout le monde sera très content de l'utiliser mais pour l'instant, il faut faire avec ce qu'on a découvert de mieux.
J'espère qu'ils gèreront d'autres protocoles ayant cette capacité.
Je ne suis pas sûr que ça vaille la peine. Weston est avant tout le PoC de Wayland et n'a pas vocation à être utiliser tel quel, ce sont plutôt les autres compositeurs qui devront les intégrer. Mais si ça t'inquiète tant que ça, il y a un backend Spice qui traine sur GitHub, même s'il n'est pas dans le trunk.
Et là je me demande, pourquoi ne pas forker dès maintenant le protocole.
Parce que ce serait casser la compatibilité avec tous les clients dès maintenant pour un hypothétique futur arrêt de la documentation.
Pérenniser le protocole de connection entre machines Wayland est un but plus important que de d'accompagner les changements d'une cible propriétaire en mouvement.
Sauf que Wayland ne gère pas le réseau, il laisse ça à d'autres protocoles.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: OSEF
Posté par claudex . En réponse au journal Le mythe de la transparence réseau. Évalué à 9.
Wayland vise à être performant et donc soit il se concentre sur l'affichage locale, soit il fait comme X et a des protocoles pour le local (DRI) et d'autres pour le distant. Mais vu que Wayland vise aussi à être maintenable, il ne veut prendre en charge différents protocole (vu que c'est une des raisons qui fait que X n'est plus maintenable).
Évidemment, si tu trouve un protocole qui rivalise à la fois avec tous les protocoles distants et locaux, tout le monde sera très content de l'utiliser mais pour l'instant, il faut faire avec ce qu'on a découvert de mieux.
Je ne suis pas sûr que ça vaille la peine. Weston est avant tout le PoC de Wayland et n'a pas vocation à être utiliser tel quel, ce sont plutôt les autres compositeurs qui devront les intégrer. Mais si ça t'inquiète tant que ça, il y a un backend Spice qui traine sur GitHub, même s'il n'est pas dans le trunk.
Parce que ce serait casser la compatibilité avec tous les clients dès maintenant pour un hypothétique futur arrêt de la documentation.
Sauf que Wayland ne gère pas le réseau, il laisse ça à d'autres protocoles.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche