Re: [vwrap] Technical basis for VW client in a web browser?

[Morgaine <[e-mail]>]

On Sat, Dec 18, 2010 at 1:51 PM, peter host <[e-mail]>wrote;wrote:

>
> To sum things up, vw protocols had better take light clients into
> account, or they will end as the next sgml.
>


While that sounds endearingly good as a sound bite, it's not when you
actually analyze it. :-)

Joshua summarized well for us the main areas in which browser-based clients
have concerns:


   - User Interface
   - 3D Rendering
   - Networking
   - Audio and Voice
   - Logic
   - Application Host/Framework


In each of these areas, you need to assess how a VW protocol interacts with
the client-side issue to understand whether the protocol creates an
unnecessary implementation constraint, or whether the problems are
self-imposed by choice of platform.  This is how browser-based clients
score:


   - *UI*:  No concern of the protocol.  Self-imposed problem.
   - *Rendering*:  No concern of the protocol.  Self-imposed problem.
   - *Networking*:  Platform defines networking to suit Web applications
   (very sensibly), which VWs are not.  (VWs have an inherently different
   network architecture to Web apps.)  Self-imposed problem.
   - *Audio and Voice*:  VW protocols don't dictate media formats, so at
   worst there is just a temporary incompatibility in the formats chosen, no
   long-term constraint.  Not really a problem.
   - *Logic*:  Virtual worlds will cover a wide range of complexities.  Some
   may be simple enough that the required program logic is perceived as "no
   download" from a user perspective, but it is not reasonable to assume that a
   majority will.  Everybody wants more features, even those users who
   illogically also want zero-download.  I would expect a huge growth in VW
   complexities, not a reduction, and this directly impacts on the size of
   program logic.  No concern of the protocol.  Self-imposed problem if a
   platform expects the impossible.
   - *Framework*:  The browser framework supports a Web app model in which
   sites are strongly isolated from each other and also isolated from
   client-side resources, in the interest of security.  The importance of this
   isolation cannot be overstated.  Unfortunately, this also means that nothing
   running in the framework can extend the power of clients on the user's
   behalf, because that would get exploited maliciously.  This is why browsers
   load extensions out-of-band ---  the actual Web application framework is too
   weak to support it, on purpose.  No concern of the protocol.  Self-imposed
   problem, but by design.


This breakdown suggests to me that the protocol is quite orthogonal to the
actual problems suffered by browser-based clients, in all areas except
networking.  And in the networking area, the "problem" stems from browser
advocates failing to understand that VWs are not Web applications, so
unsurprisingly Web browsers are not a natural host for VW clients.

There is nothing that VW protocols can do to alleviate these shortcomings of
the browser platform, because virtual worlds don't work like websites.  The
in-world objects and the avatars are highly stateful and persistent, the
users in a region all see each other, interoperating objects travel between
worlds in what would be Web cross-site anathema, and there is nothing
remotely like transparent region crossing in Web apps.  Really we're talking
about chalk and cheese here.

SGML's crown was usurped by HTML as a simpler format that worked better in
the online markup space.  But VWs are already an online space, a newer one
than the Web, and Web browsers don't work better in this new space at all.

(*Light* clients don't really have any inherent problems, by the way, other
than managing their limited resources.  Here we're talking about *
browser-based* clients which also need to be light, but they're a subset of
the category of "light clients".)


Morgaine.




=======================================

On Sat, Dec 18, 2010 at 1:51 PM, peter host <[e-mail]>wrote;wrote:

> Maybe also, one problem is the narrow definition of what a virtual
> world is or should be. LL created a very rich model, but also a very
> heavy one. Regardless of whether SL/OS virtual world clients will be
> ported to the browser or handheld devices, virtual worlds will (and
> are already, to some extent) be ported to lightweight OSes. The
> browsers ports will always be 2/3 years late, but it's always been the
> case, and as the browser security model (flawed as it is) still is
> better than most OSes security models, hence (virtual money, asset
> storing,...) I doubt support for those platforms will lag for long.
> Moreover, sofar the browser platform is as close to cross platform as
> can be. Mono will be dead before it achieves that.
>
> The big question, in my opinion, is : do SL/OS developpers
> wish/have_the_resouces to hop in the browser/handheld market (at the
> cost of graceful degradation of performances, which is an inevitable
> tradeback),... or not. If they don't others will. To take the example
> of the closed Unity model (cf. Unite, Asset Store) they already ARE on
> all browsers, but also on most TV box sets, handheld devices, and
> consoles. What makes a technology successful, in the end, is user
> adoption. Not the amazingly rich experience. (which is a shame, but
> erhhh, well...)
>
> And to the (diffuse but omnipresent) argument that OS/SL are such
> heavy, difficult, dauntingly overcomplicated project, so was Apache,
> and what happened ? Nginx happened, nodejs happened. Storing assets in
> mysql ? Gosh, how about redis, mongo, couch,... Want more sqlness,
> take riak,... Opengl on my iphone ? Hey, it's been there for years.
> Javascript too slow ? You didn't test v8 properly, and even so,
> javascript will be the glue, not the core language for libraries, etc,
> etc...
>
> To sum things up, vw protocols had better take light clients into
> account, or they will end as the next sgml. Now, that's just my
> opinion.
>
>
>
> http://twitter.com/peterhost
>
> On Dec 17, 2010, at 18:10, JohnnyB Hammerer <[e-mail]>
> wrote:
>
> > I don't understand why having a web based solution needs any
> justification by technical merits.  If those developing web based solutions
> find technical adequacy in web technologies to meet their goals I don't see
> a problem.
> >
> > I'll skip analogies involving lemmings.  ;-)  I will point out while I
> process most email with a dedicated email application I am very glad to have
> some web alternatives on those occasions that call for them.
> >
> > John.
> > _______________________________________________
> > vwrap mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/vwrap
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>