I have a worry of this turning out very badly.
Ubuntu must be eying a future alongside Android, which is an excellent bet.
There have been many attempts at X replacement, all well justified, and if Wayland is the best of them, it would still be better than the baroque X protocol.
Like almost every C++ programmer working in the early 00s, I too hacked on Berlin :-|
Ubuntu's goals do not seem to be nefarious, and almost everything they're pushing for the community is open-source, except Ubuntu One and the Software Center ability to purchase apps.
For me personally, now that nx makes X's network transparency actually usable, I'm not in a big hurry to go back to a non-network-transparent windowing system with a screenscraper like VNC layered on top. But I could see that not mattering for a lot of users, so it's probably the right choice.
Worse is better, and whoever ships a working prototype is best.
Sacrificing network transparency for local performance should be a no-brainer, given the use-cases.
There's really two parts to modern X programming: the window and event stuff, and XRender. The window and event system isn't bad, and it's fully asynchronous, which is a really big deal. XRender obviously can't be used for drawing by hand (that's why you have Cairo), but it's a really good design for a drawing protocol that supports a lot of possibilities for hardware acceleration.
Switching from TCP sockets to Unix domain sockets requires changing about 3-4 lines of connect code, but everything else remains the same. You get a lot of localhost performance for free with almost no changes.
Which makes sense. OpenGL is just an API, not a hardware wire-level protocol. Unless Wayland implements its own graphics drivers (which I find highly unlikely), it'll just make use of the same drivers that X uses for implementing OpenGL. And that still leaves things like input handling.
From the Wikipedia entry it looks like Wayland uses X for input and rendering, but other apps can connect to Wayland to have things rendered. Kind of like how X itself works.
The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X application, or a wayland client itself. The clients can be traditional applications, X servers (rootless or fullscreen) or other display servers.
They do have fairly well thought out plans for a (probably lengthy) transition of interoperating with X applications, though: http://wayland.freedesktop.org/architecture.html
Wayland is a nano display server, relying on drm modesetting, gem batchbuffer submission and hw initialization generally in the kernel. Wayland puts the compositing manager and display server in the same process. Window management is largely pushed to the clients, they draw their own decorations and move and resize themselves, typically implemented in a toolkit library.
That last part about integrating the compositing manager and display server into the same process .. that's your main point of departure.
Well, there's a bad idea. I suppose I could see an X replacement which incorporated window management into the server, instead of into a special client; but letting all the clients draw their own borders is a recipe for chaos.
I might be completely wrong about this though, so someone more knowledgeable please explain. :-)
That's the good thing, perhaps, breaking that large and ugly X thing into small parts that we can easily understand, check, improve. I'm very glad of this and it's a great improvement. But it's still just a part, this whole idea that Ubuntu is ditching X server is so frightening. It's not happening, instead, they are breaking X into small parts, improving them, not having to deal with the insanely large X stack at once. Finally cleaning that large outdated codebase and so on.
But. If you see it as 'we're getting rid of X11 completely, not coming back again', you are going to repeat every mistake made in the last 20 years. I'm afraid that's exactly what Shuttleworth and his minions are going to do :(
What does the graphics design of OSX and Windows have to do with how X is architected? Which effects provided by the OSX or Windows interface cannot be done by a compositing X window manager?
"Both Windows and OSX do remote desktop just fine for the minority who need it."
X network transparency has nothing to do with remote desktop - as a matter of fact X doesn't have that notion or any support for it. The X protocol is strictly for per-application event and drawing. There is a huge class of problems that X can solve where remote desktop would be useless.
Someone else quoted here that Wayland needs toolkit support for lots of things (moving, resizing, decorating). Are we going to see that support (possibly contributed in parts by Canonical) in gtk (and QT/KDE, fwiw)? Or is this basically going for Unity only?
In other words:
I appreciate a more modern, desktop oriented architecture. X11 seems just too much "Mainframe terminal" focused. Which is nice - but not on my laptop/netbook or in the majority of private use cases, really.
I fear, though, that this leads to a two classes of desktops for a while: The shiny Wayland one and the poor thing that still needs X11. Note that "fear" implies more emotions than reasoning - I don't know enough about Wayland support in other toolkits yet and don't understand how it could/would work with "arbitrary" setups (Open-/Fluxbox, lxde, one of the tiling wms).
Update: I was reading up on Wayland - and completely missed the blog entry from Mark. The statement "We’ll help GNOME and KDE with the transition, there’s no reason for them not to be there on day one either." removes most of my fears.
Furthermore if you checkout waylands site, you can see screenshots of various Qt and Gtk based applications running on Wayland.