X-Principles

I was reading about the history of X11 on Wikipedia while trying to fix Linux bugs and I stumbled across the principles of X. There are three I'd like to focus on, two of which I feel apply very well to X-Plane and one which does not.

The only thing worse than generalizing from one example is generalizing from no examples at all.

This is true, and in terms of X-Plane, I think this comes down to "don't add features that aren't needed." When you look at the "cost" of X-Plane in terms of how hard it is to write new code (and in some ways you could say Laminar Research does business by adding new code to X-Plane) our cost goes up with the number of existing features already in place that we have to keep working while we change things.

If a problem is not completely understood, it is probably best to provide no solution at all.

This also is very true for X-Plane. We want to provide long-term compatibility for X-Plane as a platform for airplanes, scenery and plugins. The risk of putting in solutions to problems that we don't understand is that two months later we'll go "ah drat, our APIs aren't quite right" but by that time third parties will be depending on the existing broken behavior.

Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands.

I am critical of X, but you could deflect my criticism by pointing out that it stems from how X is used, which perhaps goes against its original intention. My issues, all stemming from the use of X as the lowest level of window management are:

1. By making remote-desktop capabilities a core part of the spec, X11 introduces a complexity cost to desktop UI programming that isn't necessary a lot of the time.
2. X is not a complete solution to a desktop environment layer.

The first criticism is open to debate - who am I to say what needs to be core and what doesn't? I will only say that if I have to sit down wih the Carbon or Win32 APIs and write UI interaction code, the specification of APIs in terms of blocking and non-blocking makes UI development a lot easier than the specification of APIs in terms of two streams of asynchronous RPCs/events. So I would argue the cost is real, but whether it's worth it, well, that depends on how you use X. (I am focusing perhaps too narrowly on those who hope Linux will becomea viable desktop platform.)

The second criticism isn't even remotely fair at all - X isn't a complete solution, and it's meant to have stuff on top of it. I suppose my issue here is: X11 is pretty ubiquitous as the base layer in the Unix world, but what goes on top is open for debate.

And this goes to this third principle. If X11 is only the "bottom half" of a complete UI framework, it makes sense to provide mechanism and omit policy. But....is the bottom half of a complete UI framework useful to clients? It's the lack of policy, encoded in a simple, ubiquitous API that makes simple things easy and hard things possible, that frustrates me about coding on Linux.

So when it comes to X-Plane, I take a very different approach - I treat all of my SDK code as policy work. That is, we try to make it easy to do things we want authors to do and impossible to do things we don't want authors to do. In my experience this is the only reasonably option...given an open platform, users will do, well, everything possible.

Is it fair to be so heavy handed? Call me a techno-fascist but I think it's essential. At the end of the day, third parties count on us to keep the platform stable so that they don't have to waste time updating previous finished products each time we post a new patch to X-Plane. The wider the array of weird behavior that we tolerate, the wider the array of weird behavior we have to treat as backward compatibility cases later. By using technical limitations to require authors to conform to specs the first time, we can avoid compatibility breaks later.