Re: [vwrap] one question

["Hurliman, John" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Crista Lopes
> Sent: Friday, September 24, 2010 12:08 PM
> To: David W Levine
> Cc: [e-mail]; [e-mail]
> Subject: Re: [vwrap] one question
> 
> On 9/24/2010 11:26 AM, David W Levine wrote:
> >
> > This is a strawman in classic form. VWRAP proposes to solve a set of
> > real and useful interopability problems. Nobody has stated that it
> > solves all VW interoperability issues, and that ANYONE has to use it
> > for any purpose at all.
> >
> I understand. The issue here is one of usefulness, and you are right that you
> probably don't want to comment on that in the drafts :). If I have a client with
> a fixed viewer, then VWRAP might be useful as a standard. If I have a client
> with hypermedia, then VWRAP doesn't seem that useful as a standard. I
> think this has been a major confusion point with people whose use cases are
> the Web. For the Web, VWRAP looks like a set of prescriptions that have
> absolutely nothing to do with interoperability of virtual worlds, because I
> expect the internal engineering decisions of my virtual world to be off limits
> from anyone else. So things like the login procedure or sending the assets to
> the client are my decisions only, and no one else's business. It's very
> confusing that interoperability touches on those.
> 
> Hence the other question of whether VWRAP was even about
> interoperability or not. I actually liked Meadhbh's answer that it wasn't -- I
> thought that was very consistent with the draft.
> 
> I understand VWRAP now. It's not that useful for my use case (the Web and
> everything that already exists in it) but I have nothing else to say about it.
> 

How far can we take this line of reasoning?

OpenID is not useful for the web because it makes all these assertions about having to serve up carefully crafted HTTP endpoints with very specific content. This forces specific design decisions when I could just package up the authentication mechanism into a Javascript application that knows how to authenticate with its home server.

WebSockets is not a useful web standard because it forces me to use a specific HTTP request/response followed by a text stream over a TCP pipe. This should be an internal engineering decision! My Javascript application knows how to talk with its home server already.

Why is WebFinger trying to get into the gritty details of how to make an identity request and what to respond with? Why not just say "grab this Javascript blob and execute it and it will fetch all of the information it needs"?

Have we suddenly removed the need for all web standards other than a method of fetching Javascript blobs and executing them?

John