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

[Morgaine <[e-mail]>]

Again, +1 David.

I see no place for "*privileged groupings of services which must be
clustered and cannot be facaded or separately deployed from other services*".
The only thing that such a privileged grouping achieves is to deny
alternative patterns of deployment.

To give an example, cross-world tourism creates a complex graph of accesses
to asset services which illustrates very well how complex deployments don't
fit into the original "AD+RD" grouping at all.

A popular tourist world may attract visitors from N worlds, none of which
may know about each other.  Each visitor brings into the tourist world items
that are stored in an asset service native to the tourist's home world,
and/or stored in 3rd party asset services, and/or stored in the visitor's
own client-side asset service.

A native of the tourist world will have to be able to access not only her
own world's asset service(s), but also all of the asset services introduced
by tourists, otherwise the world will appear "broken" to her.  Even the
current region itself may introduce a new asset service particular to that
region.

The obvious way to handle such diversity is to avoid predefining any
particular clustering for asset services, but to start from the objects in
the tourist region as the source of references to asset services, and follow
the relevant URIs.

When a visitor first arrives in a region of the tourist world, the visitor's
worn items become known to the region as item references to one or more
asset services.  Whether the region chooses to (i) retrieve and cache the
corresponding data, or (ii) merely hold the references, it is a local
deployment choice.  In the first case all local participating clients will
receive local URIs to the region's own data cache, while in the second case
the clients will receive from the region the external URIs to the remote
assets services.  The latter deployment choice distributes the access load
between clients and asset services very widely across the Internet.

Making prior privileged service groupings in the manner of OGP's "domains"
makes it very difficult to handle this kind of access graph diversity, yet
this tourism deployment pattern is likely to become by far the most popular
in the metaverse, being driven by casual clicking on web pages to find
worlds of interest and visiting them.  By not predefining your service sets,
and instead just "following the data", you obtain the greatest flexibility.

Of course, there are many scenarios in which the freedom of travel needs to
be curtailed, particularly for business and security, and that is perfectly
fine and must be supported as a service option.  It should not be hardwired
into the deployment architecture though, because it is merely a  deployment
choice.  The right way to restrict access options is by configuring which
worlds and which asset services are accessible --- in other words,
service-level configuration, which has an extremely long and respected
pedigree for Internet applications.

Narrowing service deployments into predefined clusters really doesn't help
because ultimately it is the services themselves that have to be configured
and access accepted or denied.  Domains merely hardwire in a habitual
pattern and so restrict our deployment choices unnecessarily, preventing us
from deploying services in other useful patterns by simple service
configuration.


Morgaine.




=============================

On Tue, Mar 30, 2010 at 2:07 AM, David W Levine <[e-mail]> wrote:

>
> At the point where you are describing an "Authentication and Login Domain"
> "Asset Domain" "Inventory Domain" "IM Domain" you are effectively binding
> domain to type of service offered.
>
> The whole reason I an pushing back so hard on "Agent Domain" is because it
> conflates a specific deployment pattern with something special, and uses an
> already overloaded term. I think a perfectly rational and sane use of the
> term would be to follow common IT and Distributed computing practices, such
> as "Trust Domain" and "Administrative Domain" as well is "IP domain"  This
> would allow us to write statements like:
>
> "In this grid, the Login, IM, Presence, Inventory, Group, Search and
> Teleport Services live within a single trust domain. The Regions supported
> by this grid fall into separate administrative and trust domains. This grid
> access a variety of asset and micro-payment services all of which are
> outside both our trust and administrative domain."
>
> One of the pain points introduced by binding ANY grouping of services into
> the term "domain" at the architectural level is that is implies that this
> specific deployment pattern is privileged within the specifications. The
> closest that I come to thinking that really exists in VWRAP is the cluster
> of services required to support a region. Even here, tho, the pattern, as a
> web pattern, is mostly that of a facade, and the underlying deployment of
> services which actually comprise any specific region may well be separated
> across trust and administrative domains. A rather obvious example being the
> voice services in the second life grid which are delegated to Vivox,
> crossing several "domain" boundaries.
>
> If we believe there are privileged groupings of services which must be
> clustered and cannot be facaded or separately deployed from other services
> lets enumerate them and understand why they are clustered.
>
> - David
> ~ Zha
>
> _______________________________________________
> ogpx mailing list (VWRAP working group)
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>