Re: [vwrap] End point "behavior"

[Meadhbh Hamrick <[e-mail]>]

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(?)"
>
>