Talk:AWG Domain rationale discussion - Revision history

Morgaine Dinova: /* AWG components ... huh? */

2007-10-20T16:44:03Z

AWG components ... huh?

← Older revision		Revision as of 09:44, 20 October 2007
Line 22:		Line 22:
	* 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.		* 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". --[[User:Morgaine Dinova\|Morgaine Dinova]] 09:38, 20 October 2007 (PDT)		* 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). --[[User:Morgaine Dinova\|Morgaine Dinova]] 09:38, 20 October 2007 (PDT)

Morgaine Dinova: /* "Domain" must stay a root word */

2007-10-20T16:38:18Z

"Domain" must stay a root word

← Older revision		Revision as of 09:38, 20 October 2007
Line 18:		Line 18:

	: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. [[User:Dzonatas Sol\|Dzonatas Sol]] 14:27, 19 October 2007 (PDT)		: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. [[User:Dzonatas Sol\|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". --[[User:Morgaine Dinova\|Morgaine Dinova]] 09:38, 20 October 2007 (PDT)

Dzonatas Sol at 21:27, 19 October 2007

2007-10-19T21:27:49Z

← Older revision		Revision as of 14:27, 19 October 2007
Line 12:		Line 12:

	* 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. [[User:Dzonatas Sol\|Dzonatas Sol]] 08:14, 18 October 2007 (PDT)		* 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. [[User:Dzonatas Sol\|Dzonatas Sol]] 08:14, 18 October 2007 (PDT)

			= "Domain" must stay a root word =

			* In regards to the changes Zha made, [https://wiki.secondlife.com/w/index.php?title=Architecture_Working_Group_Glossary&curid=7499&diff=36987&oldid=36809]: 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 [https://wiki.secondlife.com/w/index.php?title=Architecture_Working_Group_Glossary&oldid=36987 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. [[User:Dzonatas Sol\|Dzonatas Sol]] 14:27, 19 October 2007 (PDT)

Dzonatas Sol at 15:14, 18 October 2007

2007-10-18T15:14:38Z

← Older revision		Revision as of 08:14, 18 October 2007
Line 3:		Line 3:
	[[User:Zha Ewry\|-Zha]]		[[User:Zha Ewry\|-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. [[User:Dzonatas Sol\|Dzonatas Sol]] 15:44, 17 October 2007 (PDT)		* The examples you gave are specific to a web domain and are an implementational detail. What I listed are components of the architectural domain. [[User:Dzonatas Sol\|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 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. [[User:Zha Ewry\|-Zha]] 7:00 pm PDT 17 October 2007		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. [[User:Zha Ewry\|-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. [[User:Dzonatas Sol\|Dzonatas Sol]] 08:14, 18 October 2007 (PDT)

Zha Ewry at 02:02, 18 October 2007

2007-10-18T02:02:07Z

← Older revision		Revision as of 19:02, 17 October 2007
Line 1:		Line 1:
	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"		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"

	[[User:Zha ~~Ewery~~\|-Zha]]		[[User:Zha Ewry\|-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. [[User:Dzonatas Sol\|Dzonatas Sol]] 15:44, 17 October 2007 (PDT)		The examples you gave are specific to a web domain and are an implementational detail. What I listed are components of the architectural domain. [[User:Dzonatas Sol\|Dzonatas Sol]] 15:44, 17 October 2007 (PDT)

Zha Ewry at 02:01, 18 October 2007

2007-10-18T02:01:18Z

← Older revision		Revision as of 19:01, 17 October 2007
Line 4:		Line 4:

	The examples you gave are specific to a web domain and are an implementational detail. What I listed are components of the architectural domain. [[User:Dzonatas Sol\|Dzonatas Sol]] 15:44, 17 October 2007 (PDT)		The examples you gave are specific to a web domain and are an implementational detail. What I listed are components of the architectural domain. [[User:Dzonatas Sol\|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. [[User:Zha Ewry\|-Zha]] 7:00 pm PDT 17 October 2007

Dzonatas Sol at 22:44, 17 October 2007

2007-10-17T22:44:38Z

← Older revision		Revision as of 15:44, 17 October 2007
Line 2:		Line 2:

	[[User:Zha Ewery\|-Zha]]		[[User:Zha Ewery\|-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. [[User:Dzonatas Sol\|Dzonatas Sol]] 15:44, 17 October 2007 (PDT)

Zha Ewry: New page: 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 capabilitie...

2007-10-17T22:22:08Z

New page: 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 capabilitie...

New page

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"

[[User:Zha Ewery|-Zha]]