If Or When Will X12 Actually Materialize?

[MisterIO]

I can't really see how anyone can still talk about a possible success of wayland! It's dead! Its repository didn't see any change since march: http://cgit.freedesktop.org/~krh/wayland

Don't misunderstand me, if the project comes back to life, I'll be very happy, but at the moment there's nothing that can suggest that's going to happen.

[phtpht]

rewrite the core of the xserver will sever the compatibility with everything outside bash. aka

* [enumeration of how the world as we know it will cease to exist]

Obviously noone wants to do this. This is the grand-rewrite way of the 90s. In 2010 we already know better. We know that this way brings N years of concentrated effort in the grand rewrite itself and 4*N years of suffering afterwards. By the time it's finished it's already old.

Improvements must come incrementally.

Thus: Pick one small problem in the X lib/X protocol/whatever. Write a fix. If it conflicts with something, develop it as an independent functionality. Then start migrating old clients to new functionality. Eventually outcast the old code to some 'compatibility mode' or drop it altogether. Rinse and repeat.

When the 'compat' code starts being a serious pain, outcast it even further. Change the name to X12 and put the 'compat' code in a X11 emulator for X12.

BTW. Stupidly enough the Wayland project seems to go the grand way. It will be a miracle if it manages to take off, let alone replacing X.

[V!NCENT]

Maybe this is waaaaaaaaaaay off, but is it possible make a functionality parser and replace step by step?

For example:
The parser is a yes man app, it says: "Yeah yeah yeah, I am X11... now give me your commands" and parses it to X11 as if nothing happened.
Then slowly but surely build up X12 sideways with this system in mind.
Slowly but surely, whenever some X12 feature is completed, hack and slash up the X11 feature to make it compatible with accepting that X12 feature output and slowly but surely replace everything until X12 can run on its own, individualy.
Everytime a feature is replaced, fix whatever there could be fixed in every major FLOSS app that is affected by this different behavior. Keep a schedule that is on par with the Xn (see what I did there?) schedule and maintain this list that predicts how certain apps will be affected every 6 months so people can see problems way in advance and are able to adjust their project planning slightly everytime. Do it in such a way that each time a new X12 feature is in place during a X.org release, postpone it's activation untill the next release comes around. This should give FLOSS app devs a minimum of 6 months at any given time to plan ahead.

When X13 would come around this parsing system could instantly be put in place to do the same with X12 without effort.

[V!NCENT]

PS: have this parser act as the legacy mode for parsing to X11 for older apps

[Ex-Cyber]

Modern systems are capable of supporting a much richer style of interaction than X was designed for, and have less requirement for network-extensible graphics APIs

This is true as far as it goes, but I don't understand why some people are so eager to throw out the network element. I don't think a lot of effort should necessarily go into direct support for networks, but it seems like the requirements for a stable long-lived protocol and a network-transparent protocol overlap a lot. Even among individual machines, there's a pretty wide range of "distances" between the graphics hardware and the host processor. Network transparency seems like a natural extension to supporting that range.

Stupidly enough the Wayland project seems to go the grand way. It will be a miracle if it manages to take off, let alone replacing X.

As I understand it, the main desire behind Wayland was to have a simple playground for testing various techniques with the new Linux graphics stack (KMS/DRI2). I'm pretty sure it's meant to complement Xorg, not replace it.

[curaga]

Network transparency in X was actually what I thought oodles better design after coming over from Windows. Then to find out it was actually designed years before.. Don't throw this big advantage away.

[bridgman]

Again, the real problem with "getting rid of all the bloat in X" is that nobody can agree on what that bloat actually is. For every person who says "feature X is crap, nobody uses it" there's another person saying "hey, wait, I use that all the time".

What problem are we actually trying to solve ?

[phred14]

Here's another vote for network transparency... As I sit here at my desk at work, logged into one system and accessing cycles on 3 or 4 others - at the moment. At other times I'm into more or fewer systems, but practically never confined to just the one. Or do you mean at home, where my servers are kept in a closet in the basement, but I really kind of like a GUI editor and other such tools to tweak them.

Sometimes I feel as if Linux has been overrun by Windows escapees who ironically seem to want to turn Linux into Windows. I can agree with the good of direct-access stuff for faster games, better eye candy, etc, even though I don't do much with them myself. I'm not one to say, "Don't pursue your wants - it's your code you're contributing."

But please don't take away the good stuff - like network transparency.

On another note, a really key question here is why hasn't xcb gotten any traction. This should have been something fairly minor and quite attractive, with big performance wins. Perhaps a big change at the toolkit level, but it should have been transparent above that.

Before we wonder about big changes like X12, why don't little changes like xcb get used? It's also possible that the road to X12 might be paved by small things like xcb, and it may be tough to know exactly when we got there.

[jrch2k8]

Network transparency in X was actually what I thought oodles better design after coming over from Windows. Then to find out it was actually designed years before.. Don't throw this big advantage away.

well i agree in the part of keep the network transparent part, but no the actual code. maybe something between vnc and freenx would be better or even a new protocol. but todays xorg network protocol is a massive beast wich make no sense anymore if someone even use it ofc.

anyway a ligther implementation + encryt support + maybe ssl/tls support + and faster would be awesome, in fact, in theory if the protocol is properly created you could even render opengl remotely too.

anyway i think ppl meaned ditch the code not the feature

[bridgman]

AFAIK OpenGL rendering over the wire protocol (indirect rendering, aka the GLX extension) has been around for a long time.

Since X11 refers to the protocol not the implementation, then (a) maybe X12 (protocol revision) is not really what is required, and (b) what specifically do you think is wrong with the code ?