Talk:Architecture Working Group

Separate policy from mechanism

I'm not sure where to put this in the wiki, but I would advise awareness of "The Art of Unix Programming". In particular, "Separate policy from mechanism" should be rule #1:

http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2877777

Seg Baphomet 23:14, 21 September 2007 (PDT)

This is as good a place as any. It's not altogether clear that X is a fantastic example to use to make this point. The line between "policy" and "mechanism" is rarely clear cut. For example, cut and paste between X applications is still a crapshoot (even in 2007) because I guess "how to handle the clipboard" was a policy (?) rather than a mecahnism. At the same time, "all applications must be network transparent" was baked in as mechanism, not policy (which, in the 1980s, was a pretty dubious choice, and creates optimization challenges to this day).

I'll freely admit I could be very wrong about these specific deficiencies in X. My point is merely that I'm not sure that this provides a great rule, and I worry that being too orthodox on this point can lead us to premature generalization. -- Rob Linden 13:03, 22 September 2007 (PDT)

X11's architecture was well designed for what it was designed for... which was researching window systems. Putting the policy in the application rather than the display subsystem was appropriate for that goal. Other display systems have implemented policy in required libraries (the Xerox/Apple approach) and in the display manager (Amiga Intuition, Plan 9's 8½) or in code pushed to the display from the application (NeWS and to a lesser extent Display Postscript and HTML).

Separating policy and mechanism is really just a special case of the general concept that layering should be guided by responsibilities, and that the responsibility for a given capability shouldn't be shared between layers unless necessary. ESR tends to be a dogmatic and does not seem to have had a particularly broad experience with technologies, so tends to pull examples in that don't really illustrate his points very well and stick to them when people suggest other examples might work better, but that doesn't mean his points are not, when analysed and generalised, worth paying attention to. -- Argent Stonecutter 11:12, 10 October 2007 (PDT)

I support separation of policy from mechanism as well, but I won't provide a quote to avoid opportunities for counter-quotes. :-)

Seriously, there are two very down-to-earth engineering reasons why you separate policy from mechanism at every opportunity.

• Firstly, you don't know what the required policy will actually be, except vaguely, so you have to keep it separate or else you'll be hacking around with the mechanism code, and that's extremely bad for stability. This is especially important given the scary numbers envisaged by Zero and the total uncertainties presented by a massively scaled and massively distributed system.
• And secondly, when you don't separate policy from mechanism early, then you are deferring that refactoring for a rainy day. It will always be harder and costlier to do it later, and often that difficulty and extra cost results in the work never being done at all, and hence the system limping along in its compromised state for ages.

The only really strong reason for lumping policy and mechanism together is in very time-critical code where every cycle counts, and really we're not in that ballgame at all here. I support a clean separation at this design stage. --Morgaine Dinova 08:54, 24 September 2007 (PDT)