Talk:Architecture Working Group

Keep front page clean

• The main namespace needs cleaning up. A number of recent additions are very clearly just personal Brainstorming, so that's where they should go. In particular, new proposals identified with the proposer's name certainly don't belong on the AWG front page. It has the eye of the world on it. --Morgaine Dinova 21:09, 15 October 2007 (PDT)

• I've removed the suffix "(proposal)" from Viewpoint Advocacy Groups because of the widespread support that VAGs have received, not to mention that some VA Groups are already defined and operational. --Morgaine Dinova 04:23, 18 October 2007 (PDT)

Materials

• The entries in our AWG Glossary are slowly being factored out of the actual Glossary page, and placed instead into the Description section of instances of a template. This is in principle a good thing, because it ensures that definitions appearing in more than one place cannot get out of step with each other.

• However though, for some reason, that template was named Design Document Template, as if the instances of the template document the design. They don't document the design, they merely document the terms used in the design, and in that they have a useful role. The architectural design process is not a matter of merely defining terms though, but a matter of composing well defined terms into an architecture. The template should be called Term Definition Template, so that its instances become Term Definitions.

• I've changed the reference to the glossary terms page appropriately (under Materials), but the template itself needs to be renamed also, as well as all of its instances. While "Design Document" is "just a name", choice of that name totally changes the semantics of the design process, which shouldn't have been done without discussion. Alternatively, we could throw all the VAGs and all the other resource pages in there as well, since they're all "design documents".
  

--Morgaine Dinova 12:03, 21 October 2007 (PDT)

• They are all "design documents," but the template itself is only for one category of them to make sure the descriptions of a model are mappable to each other. Other definitions that are not in the scope of the model are better put in the "Term Definitions" as you suggest. Dzonatas Sol 12:22, 21 October 2007 (PDT)

• OK, so I guess that you're saying that it's correct to stick all the VAGs documents and all other design documents on that page too, since it's simple labeled "AWG Design Documents" and doesn't refer to the fact that it's used only for glossary definition. Should we ram all of LL's design proposal documents in there as well (they're certainly "design documents"), plus all of our extensive design analysis documents, as well all of the VAG documents that impact on design? They're all "design documents" after all.

The problem isn't so much the name of the template (which could have many uses), but the fact that what should be Term Definitions have inherited the name of the template, and so has the page that gathers them together, and this conveys the wrong idea entirely, as if this were where Design is happening. It's not. Everything we write is a Design Document to the same extent as mere Term Definitions are. The naming is just not correct, and it can derail the various design groups into ensuring that their "important" documents end up there otherwise they will not be considered central "Design Documents". That wouldn't help teamwork.

I have a solution, apart from renaming the actual documents to "Term Definition", which is what they were. The solution is to delete the page that gathers them together. After all, if it's just for gathering glossary terms together, we already have that --- the glossary page! Why do we need a second one?

Alternatively, if you are intending to make that page a true index of all design documents, then everything will have to go in there, and your template is certainly not an applicable constraint since VAGs won't employ that template, and nor will countless other design documents. --Morgaine Dinova 12:44, 21 October 2007 (PDT)

• I've entered rationale on the AWG Design Document Template at the same time you entered the above comment. I believe that answered your questions, concurrently by coincidence. Let's further the discussion on its talk. Dzonatas Sol 13:01, 21 October 2007 (PDT)

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)

Proposed Architecture page extremely hard to find

Current revision of this page buries the Proposed Architecture page in a way that's really, really difficult to find. What's the best way to make sure that people can find this. -- Rob Linden 13:40, 23 October 2007 (PDT)

• Isn't that whole page structure somewhat curious? The only really good solid section seems to be Materials. I don't mind much personally, but since this is the world-facing point of entry, perhaps it merits just a little bit of extra polishing. --Morgaine Dinova 19:32, 23 October 2007 (PDT)

Agreed. What can we nuke/move to talk pages/etc? There is far more material than Linden Lab can provide effective oversight for right now. Zero apparently requested breaking things up (see Dz's comment on Category talk:AWG Design Document), and that may be helpful. I'd like to keep things out of the main namespace that don't represent the consensus view. Links to personal opinion pages should be on the Talk page, not on this page. -- Rob Linden 18:07, 24 October 2007 (PDT)

• Oh dear, we seem to have grown even more personal pages indexed from the front one, it's becoming a blog roll. This is going in the wrong direction. --Morgaine Dinova 09:10, 25 October 2007 (PDT)
• Aye Rob. In fact, some of those pages don't even deserve to be in Talk here, since they're not discussing the main page in question. I hesitate to suggest adding even more to Brainstorming, but that's exactly what some of them are. (Brainstorming is a good thing, but needs to be done in the right place.)
• "Oversight" is probably the wrong word to use, as Linden Labs is actually an enabler for community work here, which is ultimately more powerful. As Zero says, LL will not necessarily take on board everything that comes out of AWG --- some aspects may end up implemented only by third parties that interoperate with SL. --Morgaine Dinova 09:24, 25 October 2007 (PDT)