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

[Charles Krinke <[e-mail]>]

Dear Zha:

That is my understanding also. As we move forward, I can see that the notion of OGP most likely will entail a connection back to the virtual world that one teleported via 'interop' from for certain asset & inventory connections. After all, a user in OSGrid or ReactionGrid will be unknown to SecondLife and the converse is also true.

Whether we call these 'grids' or 'virtual worlds' may not matter very much. Personally, I tend to visualize all collections of regions using some sort of common User/Agent/Inventory as a 'grid' rather then a 'virtual world', but that is a small matter of semantics.

Charles





________________________________
From: David W Levine <[e-mail]>
To: Dave CROCKER <[e-mail]>
Cc: [e-mail]
Sent: Thursday, July 23, 2009 10:26:10 AM
Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds



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