Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds

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

Dave CROCKER <[e-mail]> wrote on 07/23/2009 12:05:19 PM:

> Dave CROCKER <[e-mail]> 
> 07/23/2009 12:05 PM
> 
> To
> 
> David W Levine/Watson/IBM@IBMUS
> 
> cc
> 
> [e-mail]
> 
> Subject
> 
> Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual 
Worlds
> 
> 
> 
> David W Levine wrote:
> >  > For example, by supporting different domain names an the exchange 
> > details of
> >  > protocol, a single host can run different, independent web or email
> >  > services.[1]
> >  >
> > Absolutely. There's no internal coupling, so a host offering a 
service, 
> > can either use multiple domain names, or, in fact, multiple ports
> > to host totally separate instances. 
> 
> I needed to be clearer:  I am not talking about the underlying mechanism 
that 
> gets a particular client stream to a particular server instance.
> 
> I am talking about OGP self-identifying which particular instance ofa 
virtual 
> world is the target.

I think we're getting a confusion here.. because that question sounds 
slightly ill posed. 


OGPX aspires to describe internet addressable services. Those services, 
broadly fall into
four buckets. Region services, which describe how to interact with a 
portion of virtual land.
Agent Services which describe how to interact with an agent representing a 
user, asset and inventory
services which focus on storing virtual entities to be used by users and 
regions, and the services
specific to the viewer. (The Linden Lab deployment pattern tends to 
conflate Agent and inventory/asset services)

One assembles a "world" out of some set of the services described in OGPX. 
Domains also described in the base
specs help demarcate trust/admin boundaries. From the perspective of a 
user, a "world" is a collection of regions
which share a map and consistent set of services. (such as Second Life, or 
the OSGrid or even more precisely, ReactionGrid, or
the Rezzable grid.)

At the protocol and addressing level, tho, the major addressing construct 
is URI, mostly mapped onto URLs. If one wants to
interact with the OsGrid, for example, one points one's client at OSGrid's 
Authentication and Login Service, and gives the URI of a region (or says, 
to the service "Last region I was in" 

For added fun, one can imagine Regions which are their own little domains, 
and by default users visiting get agent, asset and inventory services
from their home worlds. 

The underlying mechanism which gets you associated with a region is that 
you log in an Agent Service, and ask for you avatar to be rezzed
in a region. At the protocol level, the region is named as a URI. 



> 
> By saying 'port' you are clearly referring to reliance on TCP, or 
> the like, to 
> do the differentiation.  And indeed, it does help to have the (n-1) 
layer do 
> differential delivery.
> 
> But that's not enough.
> 
> Relying solely on the lower layers to do the multiplexing was a 
> mistake that was 
> made for email in the 70s and the web in 1989.[1]   Each needed to add a 

> within-protocol construct for identifying sources and sinks 
> independent of the 
> lower layer.
> 
> This is an example of an apparently non-intuitive aspect of what it 
> really means 
> to be transport independent, which is a stated goal of OGP.
> 
> And as long as we've (or I've) backed into that independence topic, I 
should 
> also ask about the reliance on REST.  That would seem to make OGP 
entirely 
> dependent on the Web, no?
> 
> d/
> 
REST as a design pattern. And, certainly, in the early going, most 
deployers are likely
to deliver services on http/https endpoints. The specifications explicitly 
aspire to
permit endpoints to be hosted on XMPP, or RTP, or any message oriented 
transport. 

Mind you, the basic message oriented HTTP style REST pattern does impose 
*some* constraints
in hosting an endpoint. But, the goal is to keep the resources defined as 
message sources
and sinks, which follow simple RESTish semantics. 



> [1] Oddly, this surfaced when a network link was set to loop-back and a 
host 
> delivered mail to itself, although it was intended for elsewhere...  But 
its 
> server had no way of knowing that the mail was intended for elsewhere. 
And 
> confounding this was that open relaying was acceptable then, so thatthe 
fact 
> that the RCPT-TO field had a different domain name didn't help.
> 
> -- 
> 
>    Dave Crocker
>    Brandenburg InternetWorking
>    bbiw.net