Re: [vwrap] End point "behavior"

[Crista Lopes <[e-mail]>]

You can do a client pull with JavaScript -- great!, now we can have 
VWRAP JS viewers. But you can also do a server push. And you can do all 
sorts of other things to get the assets on the user's machine. You may 
even not have assets at all -- it may all just be video streaming.

As you point your browser to different VWs on the Web, you get those 
VWs' own viewers, and it doesn't matter that they all do it in the same 
way. The way they choose to do it is an internal engineering decision.

For interoperability of VWs *on the Web*, the only thing you need is a 
shared understanding of user's identity, simulation state, and 
associated assets. Everything else is irrelevant.

On 9/23/2010 12:30 PM, Meadhbh Hamrick wrote:
> what?
>
> i have no idea what point you're making here. if you have a thin(ish)
> client that you load from a web server, it's still going to talk to
> servers out there somewhere. with CORS you can get around the problem
> of javascript only being able to talk to the server it was served
> from. thin clients talk to servers the same way fat clients do. some
> thin clients may decide to break up the task between the web client
> and a server proxy (i'm looking into this right now because WebGL
> doesn't have a retained mode.) but in that case, the proxy would be
> the client to the asset server and speak some custom protocol between
> the proxy and the web client.
>
> so why does it matter one whit if the client code was a recently
> downloaded bundle of javascript or a honkin big fat client like the SL
> viewer?
>
> i'm totally not following you here.
>
> -cheers
> -meadhbh
> --
> meadhbh hamrick * it's pronounced "maeve"
> @OhMeadhbh * http://meadhbh.org/ * [e-mail]
>
>
>
> On Thu, Sep 23, 2010 at 12:21 PM, Crista Lopes<[e-mail]>  wrote:
>    
>> On 9/23/2010 11:11 AM, Meadhbh Hamrick wrote:
>>      
>>> the great thing about standards is there are so many to choose from.
>>>
>>> if you want to use the asset and teleport portions of VWRAP without
>>> the seed cap part, go for it.
>>>
>>> it's not up to the protocol designers to decide how you wish to deploy
>>> your virtual world services. but clearly if you want to interoperate
>>> with someone who IS using the VWRAP Service Establishment pattern,
>>> you'll have to follow that draft.
>>>
>>> this is part of the "we define mechanism, not policy" mantra.
>>>
>>>        
>> This statement is true for phat clients; it is false for the web browser,
>> because for the web browser some of these "standard-compliant" mechanisms
>> are intrusions into policy and engineering design -- and irrelevant for
>> interop, as far as I can tell. The standard, for web browsers, should be
>> agnostic on these mechanisms. Putting an asset in the user's machine by
>> pulling or pushing is irrelevant, each world can do it in whichever way it
>> wants, and it will all work.
>>
>> So the drafts need to say: "if you have a client whose viewer is fixed, then
>> here are the standards necessary for interop; if you have a client that
>> takes the viewer dynamically, then these mechanisms are not necessary for
>> interop." Or else say, right upfront: "these standards are for clients whose
>> viewer is fixed; they are implementation recommendations for clients with
>> dynamic viewers based on... good practices(?)"
>>
>>
>>