Non, l'architecture de Wayland ne permet absolument pas de separer le tout. C'est juste impossible
Ben si justement. Quand tu regardes l'architecture de Wayland, tu peux justement séparer les différentes briques : Window Manager, Display Manager, Composite Manager, Events Manager, etc. (Bon en fait je ne vois pas trop l'intérêt de séparer le Display Manager et le Composite Manager et ne suis même pas sûr que c'est faisable dans Wayland). En fait, la pièce centrale est le Composite Manager et le protocole définie dans Wayland est pour justement la communication avec le compositeur ; tout le reste peut être réalisé sous forme de clients Wayland.
Toutes les implementations sures, efficaces et fonctionnelle de Wayland seront monolytique.
Oui probablement. C'est pourquoi, malgré son architecture qui permet le découplage l'implémentation qui sera faite, au-dessus de Wayland, sera monolithique ; seul le code sera structuré.
[^] # Re: Tant que ça reste coté Desktop...
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Le point sur udev et systemd. Évalué à 0.
Ben si justement. Quand tu regardes l'architecture de Wayland, tu peux justement séparer les différentes briques : Window Manager, Display Manager, Composite Manager, Events Manager, etc. (Bon en fait je ne vois pas trop l'intérêt de séparer le Display Manager et le Composite Manager et ne suis même pas sûr que c'est faisable dans Wayland). En fait, la pièce centrale est le Composite Manager et le protocole définie dans Wayland est pour justement la communication avec le compositeur ; tout le reste peut être réalisé sous forme de clients Wayland.
Oui probablement. C'est pourquoi, malgré son architecture qui permet le découplage l'implémentation qui sera faite, au-dessus de Wayland, sera monolithique ; seul le code sera structuré.