Re: [vwrap] one question

[Mike Dickson <[e-mail]>]

  On 09/23/2010 02:38 PM, [e-mail] wrote:
>
> Well, take a look at this and tell me that web, internet, and virtual 
> worlds aren’t all converging and to try to say they are separate and 
> browser are being used in the wrong way.
>
> http://robotduck.wordpress.com/2010/09/11/hometown-gp-launched/
>
> K.
>
This is simply using the web to launch into a proprietary environment 
not a use of we bbased technologies.  I say that because I was unable 
using my fully web compliant browser (on Linux) to play the game.

I'm not saying this is wrong. It's one use, one type of client 
endpoint.  An interesting one but certainly not the only one.   This is 
all consistent with past messages that said we're leveraging web 
technologies where they fit but virtual worlds does not == the web.

Mike

> ------------------------------------------------------------------------
>
> *From:* [e-mail] [mailto:[e-mail]] *On 
> Behalf Of *Morgaine
> *Sent:* Thursday, September 23, 2010 1:53 PM
> *To:* [e-mail]
> *Subject:* Re: [vwrap] one question
>
> On Thu, Sep 23, 2010 at 4:20 PM, Cristina Videira Lopes 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>> I think that answers your question from the VWRAP end, but I get the 
>> feeling there's something missing still.  Perhaps I could pose a 
>> question of my own to help the discussion:  Do you consider a 
>> "virtual world that uses the web browser as the client" to be 
>> significantly different to a virtual world that doesn't define the 
>> type of client?
>>
> No; I'm interested in virtual worlds that are Web applications -- no 
> more, no less. But the VWRAP protocol seems to be defining a specific 
> type of client, and hence, a specific way of writing the JavaScript 
> program -- at least wrt the endpoints.
>
>
> To some extent, this embroils us in issues of direction and 
> philosophy.  Some people say "We're trying to build the 3D Web", but 
> they're completely wrong, mistaking an analogy (how the Web is 
> structured and how it exploded in popularity) with the direction (to 
> create a metaverse of some kind).  Sure, we hope that it'll be as 
> large and as popular as the Web, or even more popular, but that 
> doesn't mean that the goal is in any way related to the Web.
>
> In matters of technology, we're trying to use as much Web tech as we 
> can, but again, that's not because virtual worlds have any actual 
> relationship to the Web.  It just means that we're sensibly trying to 
> ride on the shoulders of giants, reaping the benefits of very 
> efficient (and cheap) Web infrastructure.  When we link VWs to Web 
> content, that's just because people need their Web-side data or want 
> to harness Web-side functionality, and it would make no sense at all 
> to deny them access to that from within VWs.
>
> But again, that Web access has nothing to do with virtual worlds being 
> in any way related to the Web, they're not.  Indeed, they're not even 
> Web apps, they're Internet apps, and there's a significant 
> difference.  (The difference is in the data and comms models, more 
> than merely the use of particular protocols or ports.  IRC isn't a web 
> app either, despite having gateways on the Web.)
>
> Which brings us to the thorniest issue of the lot, the client.  
> Browsers are made for browsing the Web, and if at all possible one 
> should not be trying to bang in screws with a hammer.  If browser fans 
> insist on using a tool designed for a different purpose to access VWs, 
> fine, it's their choice, but it's also their problem if they find that 
> it's not a natural fit.  Perhaps they can adapt browser technology to 
> fit better, and that would be cool, but that task is theirs.  They 
> shouldn't expect the very different semantics of virtual worlds to be 
> restricted to fit into the much narrower pigeon hole of Web applications.
>
>
> Morgaine.
>
>
>
>
> ==============================
>
> On Thu, Sep 23, 2010 at 4:20 PM, Cristina Videira Lopes 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
> Morgaine wrote:
>
> But in VWRAP, it is immaterial what kind of client application runs 
> the client endpoint of the VWRAP protocols, so the phrase "virtual 
> worlds that use the web browser as the client" doesn't really make 
> much sense in our context.  The answer is *Yes* only because we 
> scratch our heads and then ignore the phrase as an unnecessary 
> condition.  Sure, why not? :-)))
>
> OK. So there are "client endpoints of the VWRAP protocol". Does this 
> mean that there are defined behaviors for a VWRAP client on those 
> endpoints? In other words, if my viewer is in JavaScript, I have to 
> make the JavaScript program do things in specific ways, and not 
> others, in order to be able to interoperate in VWRAP?
>
>
>
>
> Admittedly, your student would probably need to do some rather 
> unnatural coding since the VW model is really quite distant from the 
> Web model, and Javascript in the browser runs sandboxed so it's an 
> interesting question how your client would be coaxed to talk to 
> various external services, for example to be able to see assets worn 
> by visitors from other worlds.  (Remember that VWRAP is not tied to 
> the SL model in which everything is proxied through the current sim, a 
> highly non-scalable arrangement.)
>
> CORS addresses that issue (avoiding the jasonp trick).
> But this exposes the point I'm trying to clarify: on the web browser, 
> VWRAP seems to be *forcing* application developers to use CORS, 
> instead of leaving that as an independent engineering decision of each 
> application. Why?
>
>
>
>
>
> I think that answers your question from the VWRAP end, but I get the 
> feeling there's something missing still.  Perhaps I could pose a 
> question of my own to help the discussion:  Do you consider a "virtual 
> world that uses the web browser as the client" to be significantly 
> different to a virtual world that doesn't define the type of client?
>
> No; I'm interested in virtual worlds that are Web applications -- no 
> more, no less. But the VWRAP protocol seems to be defining a specific 
> type of client, and hence, a specific way of writing the JavaScript 
> program -- at least wrt the endpoints.
>
>
>
>
>
> I would hope your answer is "No", since otherwise it would suggest 
> that worlds are going to Balkanize by the clients they use, which of 
> course would help nobody, and interop would be compromised.
>
> Agreed.
>