Re: [vwrap] what's wrong with starting small?

[Cristina Videira Lopes <[e-mail]>]

Since OpenSim does not assume that there is 1 single data format for  
these exchanges (because there are 2 at the moment), we have recently  
introduced a step of protocol negotiation. The sim asks the server  
"what kind are you?" and instantiates the right connector to it. I'm  
not particularly fond of protocol negotiation, but I see some social  
advantages in having it: no one needs to agree on one single data  
format, and the door is always open for someone to come in with some  
creative alternatives. As far as OpenSimulator goes, if there's an  
opportunity for diversity, we usually take it.

WRT the boundaries of interoperation. In HG1.5, there is a clear  
distinction between internal interfaces (i.e. how simulators and  
resource services interact within the same domain of trust) and  
external interfaces (i.e. how simulators interact with services  
outside their domain of trust). Teleporting, for example, is done  
differently. So is inventory access. Potentially, every interaction  
between components in different domains of trust are done differently  
than they would be done within the same domain of trust, for a  
performance vs. security tradeoff.

The notion of domain of trust is paramount to HG1.5, because people  
want nothing to get in the way of performance when they know that the  
machines are under their complete control.

On Sep 22, 2010, at 2:13 PM, Hurliman, John wrote:

> We're working on implementing HG 1.5 support in SimianGrid right now  
> which introduces asset fetching across trust domains. Crista could  
> describe the implementation details better.
>
> On a side note, I realize that only defining teleport is not very  
> useful if you're try teleporting from Kevin's web-based virtual  
> world to an OpenSim instance that use completely different state  
> synchronization protocols. At best that would end with the web-based  
> client completing the teleport, OpenSim waiting for a UDP connection  
> to be established, and the client and server both timing out. But  
> you *would* be able to teleport from an OpenSim world to another  
> OpenSim-compatible world, and it lays the foundation to start  
> talking about next steps if we want to go further.
>
> John
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On  
>> Behalf
>> Of Morgaine
>> Sent: Wednesday, September 22, 2010 1:58 PM
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: Re: [vwrap] what's wrong with starting small?
>>
>> Thanks for the link, Crista!  John's email mentions:
>>
>>
>>
>> *	Identity/Authentication
>> *	Assets (possibly Inventory, maybe)
>> *	Teleport (both login and simulation to simulation)
>>
>>
>> Let's talk about Assets. :-)
>>
>> Beyond a small amount of discussion and agreement with Joshua last  
>> year
>> on basic requirements that would enable inter-world tourist use  
>> cases,
>> there has been virtually nothing discussed in VWRAP about this core
>> topic without which everything else is singularly uninteresting.
>>
>> About a year ago, I spoke to John about the need for replacing the
>> singleton inventory/asset service in Cable Beach with a more flexible
>> one to allow inter-VW tourism, and John said that his singleton was
>> just a temporary feature in his prototype and would be improved.  Has
>> there been any progress on that in the offspring of CB, ie.  
>> SimianGrid?
>>
>> Staying with "State of the Union" topics, if we're merging VWRAP and
>> OpenSimulator efforts, would you like to give us a description of  
>> asset
>> handing in the new HG1.5 and where you expect HG2.0 to be heading?
>> Asset handling on interop is exactly the kind of topic that we need  
>> to
>> have examined in depth before we can write initial drafts that have a
>> chance of being relevant. :-)
>>
>>
>> Morgaine.
>>
>>
>>
>>
>>
>> =========================
>>
>>
>> On Wed, Sep 22, 2010 at 7:06 PM, Cristina Videira Lopes
>> <[e-mail]> wrote:
>>
>>
>> 	http://www.ietf.org/mail-archive/web/vwrap/current/msg00318.html
>> 	If you are talking about *this* email from John, we are on the
>> same page.
>>
>>
>> 	Meadhbh Hamrick wrote:
>>
>>
>> 		so we have a recommendation from at least two implementers
>> (myself and
>> 		john) that we focus on a small subset of an overall virtual
>> world
>> 		problem domain.
>>
>> 		it seems to me that diva/christina and morgaine are pushing
>> for a more
>> 		expansive problem domain.
>>
>> 		can i ask, what is the issue we have with starting small
>> and then
>> 		growing the problem domain?
>>
>> 		i think i remember an IETF "old hand" (it might have even
>> been barry)
>> 		say that it's a LOT easier to go back to the IAB / IESG and
>> ask to add
>> 		things to your charter than it is to remove them.
>>
>> 		i'm also thinking that some of the tension in this group is
>> over the
>> 		conflicting objectives between the "expansionist" block and
>> the
>> 		"dimunitivist" block. but it also seems that we're not
>> horribly far
>> 		off from each other in terms of wire protocol.
>>
>> 		maybe a solution could be to draft two documents... one a
>> "long term"
>> 		goal for virtual worlds that describes the "expansionist"
>> objectives
>> 		and another that is a little more short term and describes
>> the
>> 		"diminutivist" objective for a small subset of things
>> needed for the
>> 		long term goals?
>>
>> 		is the concern with this approach that any near term
>> service (service
>> 		establishment, event queue, teleport, assets) would need to
>> know about
>> 		the totality of the virtual world in order to be practical?
>>
>> 		-cheers
>> 		-meadhbh
>> 		--
>> 		meadhbh hamrick * it's pronounced "maeve"
>> 		@OhMeadhbh * http://meadhbh.org/ * [e-mail]
>> 		_______________________________________________
>> 		vwrap mailing list
>> 		[e-mail]
>> 		https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>>
>>
>> 	_______________________________________________
>> 	vwrap mailing list
>> 	[e-mail]
>> 	https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap