Respuestas:
¿Por qué no Wayland / Weston?
Una aclaración obvia primero: Wayland es una definición de protocolo que define cómo una aplicación cliente debe comunicarse con un componente compositor. Toca áreas como la creación / destrucción de la superficie, la asignación / administración del búfer gráfico, el manejo de eventos de entrada y un prototipo aproximado para la integración de componentes de shell. Sin embargo, nuestra evaluación de la definición del protocolo reveló que el protocolo Wayland no cumple con nuestros requisitos. Primero, nuestro objetivo es un manejo de eventos de entrada más extensible que tenga en cuenta desarrollos futuros como dispositivos de entrada 3D (por ejemplo, Leap Motion). Sin embargo, tenga en cuenta que el manejo de eventos de entrada de Wayland no sufre los problemas de seguridad introducidos por la semántica de manejo de eventos de entrada de X (gracias a Daniel Stone y Kristian Høgsberg por señalar esto). Con respecto a los casos de uso móviles, creemos que el manejo de los métodos de entrada también debería reflejarse en el protocolo del servidor de visualización. Como otro ejemplo, consideramos que las partes de integración de shell del protocolo son privilegiadas y preferimos evitar tener algún tipo de comportamiento de shell definido en el protocolo de cara al cliente.
Sin embargo, todavía creemos que el intento de Wayland de estandarizar la comunicación entre los clientes y el componente del servidor de visualización es muy sensato y útil, pero debido a nuestros diferentes requisitos, decidimos optar por la siguiente arquitectura wrt para la integración de protocolos:
Un núcleo interno independiente del protocolo que está extremadamente bien definido, bien probado y portátil. Un shell externo junto con un firewall frontend que nos permite portar nuestro servidor de visualización a pilas de gráficos arbitrarios y vincularlo a múltiples protocolos.
En resumen, no hemos elegido Wayland / Weston como nuestra base para ofrecer una experiencia de usuario de próxima generación, ya que no cumple con nuestros requisitos por completo. Además de esto, con nuestro enfoque independiente de protocolo y plataforma, podemos asegurarnos de alcanzar nuestro objetivo de una experiencia de usuario coherente y hermosa a través de plataformas y factores de forma de dispositivo. Sin embargo, el soporte de Wayland podría agregarse ya sea proporcionando una implementación de interfaz de usuario específica de Wayland para nuestro servidor de visualización o proporcionando una implementación del lado del cliente de libwayland que finalmente hable con Mir.
Aquí hay una discusión más detallada: https://wiki.ubuntu.com/Mir/Spec?action=show&redirect=MirSpec
Y del arquitecto técnico Mir:
http://samohtv.wordpress.com/2013/03/04/mir-an-outpost-envisioned-as-a-new-home/
Más información:
Jono Bacon en su Q y A ha respondido esto varias veces. Su última respuesta está aquí:
http://www.youtube.com/watch?v=6Oa2psAewtg&feature=share&t=56m36s
Por lo que he recopilado de los gustos de las preguntas y respuestas de Jono y los comentarios de Popey sobre Linux Unplugged, los puntos se pueden resumir de la siguiente manera: