Talk:AWG Domain rationale discussion

I have a hard time with the current listed set of domains. A set of components is, not at all a domain. A domain might be "all Linden Labs trusted servers which use lightweight capabilities within the LL firewall to manage trust" a domain might be "A set of asset, simulation and region servers which share a single trust domain"

-Zha

• The examples you gave are specific to a web domain and are an implementational detail. What I listed are components of the architectural domain. Dzonatas Sol 15:44, 17 October 2007 (PDT)

I refer you to the definition provided. An enumeration of words does not form a terribly useful domain, and a flat list of phrases sharing no common characteristics other than the fact that they are a collection of concepts and phrases found in the overall discussion of the architecture doesn't seem terribly useful.

I, for example can certainly believe that there will be a concept of identity within the architecture. There may even be a highly specific form of identity which we will define as what we mean when we, in detailed flows, say things like "The user passes his or her identity to the client, which passes it to the authentication service." What I have a much harder time imagining is that there will be a component, or resource which is identity, which might be usefully grouped into a domain. -Zha 7:00 pm PDT 17 October 2007

• The question to ask: What are the components of the Architectural Standards Working Group? There are two sides to that answer because there is the entire design and the entire model. So far, the ASWG has started from a basic model but no design. The ASWG needs to first design its own workflow based on prior model requirements and expand that model further.

• When you say, "grouped into a domain" and "user passes his or her identity" that sounds like implementation details. My view is different. I look at "identity" as a component of the Architectural Standards Working Group as a piece to design the product, but I also understand your view that is "identity" as a piece of data being networked by the product. Dzonatas Sol 08:14, 18 October 2007 (PDT)

"Domain" must stay a root word

• In regards to the changes Zha made, [1]: those examples are valid domains but to limit the scope of the word Domain will create us more work. I have found in the past with software development that this kind of method to scope and redefine words can waste a lot of time. It is much easier to use a phrase, create new words, or borrow other symbols to get the ideas out. The redefinitions to match one view will prevent any creativity into a new view. We may need to work within another view. To have complete freedom of which view to work from is key to object orientated design. To create a glossary first and then say the design must fit the glossary is not object-orientated design at all. That is like being strictly limited to primitive implementations and only use those to design the next architecture. I do understand the need to have some common ground on words and confirmations of the views, but the that glossary version is not the best way to do it. We have some resources available to us now to resolve these kinds of issues easier in a partial object-orientated way. We need to use that ability more to design, design, and design.

My suggestion on new words can be used, or we can use more structural methods. The example given to expose services can be called "interdomain objects" and replace "objects" with whatever scope they have on the view. Components that are not exposed can easily be said "intradomain components." Anybody can laugh at the funny names all they want, but they won't laugh away at how much it saves in cost to design and implement. Dzonatas Sol 14:27, 19 October 2007 (PDT)