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)

AWG components ... huh?

• This page made a lot of sense to me, give or take a point or two, until I got to this last section. Then I completely fell off the log. I have no idea what it means whatsoever. The items mentioned have no useful common point of reference, they're not components in any strong way, and they are only related to AWG through the fact that we talk about them occasionally because they have some relevance to SL and to future architecture. Even worse though is the analysis by exclusion. So many (dozens or hundreds) of things are not mentioned in that list that the few that are simply don't represent anything useful.

• I would like to bring to our attention (again) the key lesson of IEEE-1471: do not attempt to subdivide the architecture a priori, because you will always get it wrong (there is no right). You can always enumerate elements of course, but it doesn't really serve a particularly useful purpose except as an index. And you can also group similar elements into classes of those elements (as in the case of Domains), because that's not a subdivision and so doesn't impose an actual restriction. Any other classification "is just one view".

• I recommend that this section be deleted, leaving only a discussion about "Domain" (not AWG Domain, that's in bad conflict with LL's use of "Domain", and serves no purpose in AWG either, as above). --Morgaine Dinova 09:38, 20 October 2007 (PDT)