Re: [vwrap] Consensus? What exactly should be in the protocol

[Meadhbh Hamrick <[e-mail]>]

christina,

i think you may be missing the point of capabiliies a bit. they're in
the mix here so we can avoid the confused deputy problem and have
"loosely coupled" collections of services. CORS does allow you to do
mashups in a user agent, but CORS in and of itself says nothing about
trust with respect to the server side.

in other words, if i want to create an application that is a composite
of two services, each of which touches "sensitive" data, i have to
have a way for the client to authorize itself to both services.

you can do this with something like SAML and you can use OAuth as a
way to carry proof of authorization. but you would still need trust
relationships between the two services for this to work. capabilities
allow us to use a "transitive trust" model that reduces the
requirement for a federated identity / trust model.

and i like that idea.

however, you can compose something like SAML + OAuth with
capabilities, but you can't go the other way.

SAML and OAuth are GREAT technologies to use for certain problems, but
the world is more than a browser or client. some use cases require
services to either trust each other (independently of trust stitched
together by the client) or to trust the people they trust without a
pre-existing direct-trust relationship.

so it's all about whom you trust. my take on the tourist model is that
it's the client that decides whom to trust. and my take on the
HyperGrid model is that it's the simulator that decides whom to trust.
what we want to build with the use of capabilities is the generic
ability of an auth service that decides whom to trust, even if there
is not an existing trust relationship between the client and the
non-auth service.

i wonder if it's possible to define RESTful VWRAP resources
independently of them being behind capabilities. if you're really down
with using traditional web auth, this might be an answer.

we could define a cap based service establishment protocol flow, but
make it independent of the use of other defined resources. so if they
service establishment were defined with RFC XXXX and some other
service were defined in RFC YYYY, you could deploy a RFC YYYY service
without the benefits of RFC XXXX. it should be straight-forward to
even code this.

if you really have a use case for direct-trust only, laissez les
bontemps roullez!

does this make sense?

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [e-mail]



On Wed, Sep 22, 2010 at 11:07 AM, Cristina Videira Lopes
<[e-mail]> wrote:
> All the limitations that you mention about the Web architecture not being
> enough to support virtual world applications have been muted by HTML5.
> Additionally, CORS now allows for true client-side mashups.
> But even without these two things, you can build non-web-browser clients
> that follow the general principles but that do special things for the
> real-time updates -- basically, the general concept of JavaScript+WebSockets
> done in whatever other way you like: different programming language,
> different protocol,...
>
> The really important architectural principle, though, and one that is
> unlikely to be let go, is that the use of WebSockets, the data formats that
> flow through them, and the use of CORS, are decisions that pertain to *each*
> virtual world application, it's not something that is imposed on all VWs by
> web standards -- it comes as JavaScript sent by the server! They are
> *implementation options* -- very valid options, I must add, but options
> nevertheless. What you are trying to do here is to dictate that all virtual
> world applications MUST use some protocol for renderer -- server
> interactions, down to the data formats, and MUST use capabilities for
> mashing things up, or else... they can't interoperate.
>
> You can dictate that. But then this will be completely irrelevant in a
> couple of years when WebGL is actually usable or when Google finishes their
> virtual machine for running safe native code on browsers.
>
>
>
> David W Levine wrote:
>>
>> So, of course we're building in the web space. I hope nobody is denying
>> that. In fact if you look at everything described in VWRAP is starts with an
>> assumption that most services are delivered as REST or REST like services. I
>> think its safe to say that the people who have been discussing this for over
>> two years are aware of Roy's work, and have thought about how REST applies
>> to virtual worlds. REST represents a lot of thinking about how the web
>> delivers content, and in particular why not to turn the web into a
>> distributed object model, or a shared state model, but rather to leverage
>> the observed successful patterns of the web in managing distributed
>> programming problems.
>>
>> But.. (There is always a but) The very core thing that a virtual world
>> does doesn't fit terribly well into the mainstream web model. The heart of a
>> virtual world is delivering (and Morgaine's phrase serves very well here) a
>> visual mashup of things to users 30-60 times a second, updating continually
>> to reflect the input of the physical simulation, any user
>> inputs, and any scripted inputs. Our core problem is taking in the inputs,
>> deriving the new state and sharing it out to the users. This isn't really
>> what the web has historically done. The fact that it isn't, that there are
>> some really interesting distributed system challenges at the very heart of
>> this, is part of its technical appeal to me.
>>
>> Life is made harder by the fact that the virtual space is being constantly
>> asked to accept new things to deal with. Every time an avatar arrives it
>> brings a set of stuff
>> which has to be melded into the scenegraph. Again, we all know this.
>> Rezing an avatar means adding a bunch of new content to the virtual space,
>> and it means pushing
>> it back out to all the observers.
>>
>> In the traditional web you go to a URL, you do a get, and you get handed a
>> huge slab of stuff to render.(some of which may require fetches, plugins,
>> etc.) In the more dynamic 2.0 style stuff, the stuff you get may include
>> dynamic elements which fetch and update more stuff. In the virtual worlds
>> space, we bring to to a fever pitch. we take inputs from all the present
>> users, from a simulation, including the scripted changes within the
>> simulation. We then turn around and want to show this to the user.
>>
>> How do we present this to the user. Well, we currently use Linden's
>> UDP/http/longpoll tangle. Fine. But. how could we do it?
>>
>> We could create a video stream and stream it. (WHich isn't very web page
>> like at all, but has some nice properties)
>> We could do something like OnLive where we would create a very tailored
>> stream and deliver it to a client with very specialized coupled inputs (And
>> life with a lot of
>> constraints and again isn't very web page like)
>> We could send a stateless update every frame for the client to render
>> (Well, with ulimited bandwidth and processor power)
>> Or.. we could do what we currently do, just cleaner. which, roughly
>> speaking is send down initial state and then send down a series of updates
>> to that state. Woah, not
>> exactly a traditional web page. Worse still.. where do we post the inputs
>> from the client to the world?
>>
>> At the same time, we also get to ask "How do we get all the "stuff" into
>> the region. In Linden's world, the answer is easy. They use a proprietary
>> protocol and fetch it from
>> their creaking central servers. In OpenSim, a similar answer obtains. And
>> for added pain which we have all shared, the current set of clients push all
>> the stuff related to
>> the user via the region.
>>
>> VWRAP attempts to describe nothing more than a set of REST web services
>> which represent the region and the services. It attempts to leverage what's
>> been learned from REST, and Linden's system, and in fact OpenSim, to
>> describe a simple, extensible set of services which can describe: Regions,
>> Auth services, how to rez and unrez avatars, how to (when we get some
>> writing down) fetch and manipulate assets, inventory lists and so on.
>>
>> What you end up with is built deeply on web principals, but not a web
>> page, but mostly because a virtual world is not, at its heart a web page,but
>> a set of services collaborating to
>> share state in a pretty unusual way.
>>
>> - David
>> ~Zha
>>
>
>