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)

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)