L’architecture serveur/client Xorg permet la transparence du réseau, ce qui signifie qu’il est possible de démarrer des x-clients sur une machine distante et d’afficher l’interface graphique sur la machine locale (c.-à-d. Via x-forwarding en utilisant ssh).
Wayland aura-t-il la même manière ou une manière similaire de permettre d'afficher les interfaces graphiques d'applications sur un système différent de celui qu'elles exécutent?
Cette fonctionnalité devra-t-elle être présente avant de prendre des mesures pour remplacer Xorg par Wayland sur les systèmes Ubuntu?
Selon http://mmol-6453.livejournal.com/253081.html , la transparence du réseau figure dans la liste des tâches à effectuer, elle se trouve simplement au bas de cette liste. Si ce qui est dit est vrai, nous pourrons éventuellement nous connecter graphiquement à une autre machine et exécuter des applications, mais pas immédiatement, et probablement AVANT que X soit abandonné. J'espère que cela est vrai, car, à l'instar des autres ici, je considère qu'il s'agit d'un avantage primordial pour un système basé sur X par rapport à d'autres, tels que Windows.
Je crois comprendre que X sera capable de fonctionner au-dessus de Wayland en tant que client. Voir les diagrammes au bas de http://wayland.freedesktop.org/architecture.html par exemple.
Ils ne mentionnent cela qu'en termes de possibilité de partager des périphériques d'entrée avec X pour une compatibilité ascendante, mais je suppose que cela signifie qu'il sera possible de communiquer avec le serveur X via une connexion distante même s'il fonctionne sur Wayland.
Je ne connais aucune application graphique que je ne puisse pas lancer via une session SSH. Moi, et probablement tous les gens que je connais professionnellement, utilisons cela tous les jours. Pas seulement au travail, mais à la maison aussi. Compiz et autres effets sympas sont un luxe. La transparence du réseau pour chaque application graphique que je pourrais installer est un exigence. RDP ou VNC sont des substituts inacceptables.
Tout ce que je peux voir sur ce sujet, ce sont des commentaires du type "ne vous inquiétez pas, parce que ... [insérez des mots qui me font craindre ici].
Ce que je veux, c'est que quelqu'un qui développe Wayland dise publiquement "ne vous inquiétez pas, car" la transparence du réseau est notre priorité absolue ". Ils savent que nous voulons entendre cela, mais ils ne vont pas le dire sans protection.
La réponse correcte est: "La transparence du réseau n'entre pas dans le cadre du protocole Wayland".
Une explication complète est fournie dans cette FAQ mais un bref résumé pourrait être: "le but de Wayland est de définir un petit protocole, en essayant de rester à l'écart de la plus grosse erreur de X: faire et mandater trop (X avait même un serveur d'impression !!!). Compte tenu de ce concept, il n'y a aucune raison exceptionnelle d'ajouter de la transparence réseau dans le protocole Wayland. Cela peut être fait dans une API autonome et son serveur/client. Rien dans le protocole Wayland n’est contraire à la transparence du réseau. "
Une chose à noter est que les implémentations X actuelles ne sont plus transparentes au résea , comme l'explique Daniel Stone dans cette vidéo (que vous devriez vraiment voir si l'argument vous intéresse et si vous voulez avoir une bonne - rire - rire).
Aucun Wayland n'est moins ambitieux que Xorg et n'aura pas de transparence de réseau.
Citant le blog de Mark Shuttleworth:
Certains des objectifs principaux de X rendent plus difficile la réalisation de ces expériences utilisateur sur X plutôt que sur un GL natif. Nous choisissons donc de privilégier la qualité d’expérience par rapport aux valeurs initiales, telles que la transparence du réseau.
ref: http://www.markshuttleworth.com/archives/551
En tant qu'opinion personnelle, je ne pense pas que la transparence réseau du "serveur" graphique soit une fonctionnalité nécessaire pour un ordinateur de bureau, c'est une fonctionnalité qui correspond le mieux à l'architecture tiny_client/big_workstation.
La capacité de Wayland à exécuter un imbriqué X signifie qu'il sera possible de prendre en charge la plupart des situations de transparence réseau et des fonctionnalités similaires. Aussi, j'ai lu que cette fonctionnalité pourrait être remplacée par une meilleure méthode (si je peux retrouver le lien, je le fournirai).