Re: [ogpx] verbiage : domain, agent domain, region domain, trust domain, service, etc.

[David W Levine <[e-mail]>]

Meadhbh Hamrick <[e-mail]> wrote on 03/29/2010 04:54:31 PM:

> [image removed] 
> 
> Re: [ogpx] verbiage : domain, agent domain, region domain, trust 
> domain, service, etc.
> 
> Meadhbh Hamrick 
> 
> to:
> 
> David W Levine
> 
> 03/29/2010 04:55 PM
> 
> Cc:
> 
> ogpx, ogpx-bounces
> 
> so i said services contain "protocol endpoints" rather than
> "capabilities" as it's possible for services to have well defined,
> public endpoints that are NOT capabilities.
> how 'bout...

Quite right, on "service endpoint" my bad.

> 
> the terms "asset domain" and "region domain" are used to identify the
> domain of certain types of transactions in the protocol. their use
> underscores the potential separation of the roles each domain plays.
> 

In some deployments mayhap. Not in all. The roles the domain plays in 
these
examples is a deployment choice, nothing more. There may be some 
trust/admin
patterns which are common, but then we need to focus on those rather than
thinking calling it an "agent domain" is clarifying. 


> so the terms "agent domain" and "region domain" are "positional" and
> describe the function in a protocol transaction, NOT a requirement
> that a group of machines implement a particular cluster of services.
> --
> meadhbh hamrick * it's pronounced "maeve"
> @OhMeadhbh * http://meadhbh.org/ * [e-mail]
> 

But, positional terms which describe specific patterns, which are 
deployment choices rather
than functional requirements actually confuse not clarify. 

> so we would say, "the agent domain initiates the process of placing an
> agent in a region domain's simulator" rather than "the first service
> initiates the process of placing an agent in a region."

It might. Or the authentication service might give you NOTHING more than a 
sheaf of
seed caps each on a stand-alone service which is separately deployed. (I 
think that's
not going to be the most common deployment pattern, but its certainly one 
you could deploy,
and one we need to be able to describe. 

Unless we can say "This is a term which always cuts things into separable 
parts", I think we're 
confusing deployment with architecture. To the degree you can say why 
"Agent Domain" is more
explanatory than saying "This common cluster of services" in which case 
I'm perfectly happy saying that. But
I'm thinking that beyond a very small cluster (Auth, IM endopint, Presence 
broadcast, and even those could be delegated) I'm not sure what HAS to be 
in an Agent Domain, rather than what many people will CHOSE to put in one. 


Please note I think this is exactly the discussion we *should* be having. 
We need to make it clear what the term
is actually buying us, and how we could benefit from it. 

- David
~Zha