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

[Cristina Videira Lopes <[e-mail]>]

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] <mailto:[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] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/vwrap
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>