Difference between revisions of "AWG Domain rationale discussion"

From Second Life Wiki
Jump to navigation Jump to search
Line 1: Line 1:
'''This is intended to explain, in some detail, the basis for the definition offered in the glossary. Please feel free to add to it, ask questions, and generally help articulate this more clearly'''
'''This is intended to explain, in some detail, the basis for the definition offered in the glossary. Please feel free to add to it, ask questions, and generally help articulate this more clearly'''


[[Architecture Working Group Glossary|Glossary#Domain]]
[[Architecture Working Group Glossary#domain|Glossary entry]]


In normal usage, within computer architecture, a domain is a span of authority or trust, or in the case of DNS, a subtree of name space. Linden has proposed splitting the current flat system into an agent domain, and a region domain, and then, multiple agent and region domains. (in the 2008 picture, we see SecondLife Agents, XYZ Employees, XYZ land, and LindenMainland, as examples of domains, as well as a third domain, marked as central utilities. This strongly implies that domains which are both functional as well as trust/authority based.  
In normal usage, within computer architecture, a domain is a span of authority or trust, or in the case of DNS, a subtree of name space. Linden has proposed splitting the current flat system into an agent domain, and a region domain, and then, multiple agent and region domains. (in the 2008 picture, we see SecondLife Agents, XYZ Employees, XYZ land, and LindenMainland, as examples of domains, as well as a third domain, marked as central utilities. This strongly implies that domains which are both functional as well as trust/authority based.  
Line 8: Line 8:


So... abstractly, a domain is a grouping of resources which have some properties in common, such that we can use those properties when structuring the system, on an architectural level.  
So... abstractly, a domain is a grouping of resources which have some properties in common, such that we can use those properties when structuring the system, on an architectural level.  
In software terms we could imagine having an web service which permits us to determine the membership and the properties of a domain. (This would require having useful markup for these properties) Note that both explicit and implicit domains exist in the current world. (any machine that is resolvable  as .ibm.com
is in the .ibm.com domain in DNS space, even tho we cannot fully enumerate them, and they share no other properties.  All the machines in a lan server domain may be enumerable, and share a single administrative password.


[[Category:Architecture Working Group]]
[[Category:Architecture Working Group]]
[[Category:AWGroupies]]
[[Category:AWGroupies]]

Revision as of 11:36, 17 October 2007

This is intended to explain, in some detail, the basis for the definition offered in the glossary. Please feel free to add to it, ask questions, and generally help articulate this more clearly

Glossary entry

In normal usage, within computer architecture, a domain is a span of authority or trust, or in the case of DNS, a subtree of name space. Linden has proposed splitting the current flat system into an agent domain, and a region domain, and then, multiple agent and region domains. (in the 2008 picture, we see SecondLife Agents, XYZ Employees, XYZ land, and LindenMainland, as examples of domains, as well as a third domain, marked as central utilities. This strongly implies that domains which are both functional as well as trust/authority based.

Pragmatically, domains are only useful, if they give us some leverage in building the system. In other words, when we separate a set of components into a domain, we should expect to gain some technical leverage from the distinction. Grouping services by trust, for example permits us to use lower cost mechanisms to establish trust between services in the domain. Grouping services by function, seems less obvious, unless there is a very specific load balancing benefit from the grouping. (There may be perfectly good reasons for a company hosting a service to group servers by function for administrative purposes, but.. that probably is nicely out of scope for an architectural distinction)

So... abstractly, a domain is a grouping of resources which have some properties in common, such that we can use those properties when structuring the system, on an architectural level.

In software terms we could imagine having an web service which permits us to determine the membership and the properties of a domain. (This would require having useful markup for these properties) Note that both explicit and implicit domains exist in the current world. (any machine that is resolvable as .ibm.com is in the .ibm.com domain in DNS space, even tho we cannot fully enumerate them, and they share no other properties. All the machines in a lan server domain may be enumerable, and share a single administrative password.