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

[<[e-mail]>]

The protocol will only be obsolete if it is not designed to support new
formats or varied formats, or have any discovery or caps ability.

 

Maybe others are working on some avatar format, I don't know of one.  But
here is kind of thing I am working on; it isn't fancy but probably handles
most things we see today.

 

Just as an example Avatar Manifest

1.	List of Objects
2.	List of attachment points
3.	References to actual physical objects
4.	List of animations
5.	Animation name mapping to public capabilities specification
6.	List of gesture or others script based capabilities.

 

It is really true that VWRAP will not have a specification on the avatar.
How can one avatar go to another space without that?  How will I know how to
expose my avatar to another space without it?

 

Regards,

K.

  _____  

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Cristina Videira Lopes
Sent: Wednesday, September 22, 2010 3:09 PM
To: Morgaine
Cc: [e-mail]
Subject: Re: [vwrap] Consensus? What exactly should be in the protocol

 

Perhaps we should all step back until *someone* sends a draft that actually
captures this? 
Which is not the current draft :)


Morgaine wrote: 

Indeed, standardizing on data formats would result in a protocol that is
obsolete before it's released.  Which is why VWRAP doesn't do that. :P

Instead (using my own form of words here to try to make this more
understandable), VWRAP is concerned with "gluing together" services in a
highly dynamic and flexible manner.  Those services can be switched and
extended at a moment's notice, under the control of the VWRAP protocol, not
only to extend the feature set but also to alter the particular deployment
pattern in use, if this is desired.

VWs are expected to evolve and change drastically over the next several
years, so adaptability in a world of continuous change is paramount, so we
have stressed the need for extensibility a lot.

The following should really go without saying, but I'll say it anyway in
light of a recent comment --- VWRAP extensibility does not mean "go back to
the IETF for another round of standardization".  It means that outside of a
small neutral core, the protocol is dynamically extensible on demand,
specifically by hooking in improved services, or indeed totally new ones.
Revision of the core protocol should only be required if the old one is
found to be incapable of adequate orchestration of improved services.  To
the best of our ability, we will try to make this unnecessary.

Think of VWRAP as the Unix shell --- you rarely need to change it!  The
shell is just the glue by which you assemble suites of processes to do the
actual work in Unix.  In VWRAP, the VWRAP protocol glues together VWRAP
services in a similar fashion.

There's a lot of work to be done before this becomes a reality of course.


Morgaine.





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

On Wed, Sep 22, 2010 at 7:07 PM, 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

 

_______________________________________________
vwrap mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/vwrap





 





  _____  



 
_______________________________________________
vwrap mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/vwrap