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

[Morgaine <[e-mail]>]

There's a general misapprehension about size and complexity in the core
protocol.  All it's meant to be doing is gluing together services, so if
it's "boiling the ocean" then someone has designed it wrong.  The complexity
is meant to be in the services!  If the services are being hardwired into
the core protocol then it's certainly not extensible, so that prototype has
failed.  Rewrite it, iterating through services supplied on a list.

On a broader note, I'm going to ignore remarks about "boiling the ocean",
because the phrase has been used repeatedly in this group's past as a way of
simply dismissing other people's suggestions.  That doesn't work.  If there
is a technical problem with a suggestion, describe and discuss the technical
problem.  Warming water is not in scope.


Morgaine.





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

On Wed, Sep 22, 2010 at 8:21 PM, Meadhbh Hamrick <[e-mail]>wrote;wrote:

> On Wed, Sep 22, 2010 at 11:58 AM, Morgaine
> <[e-mail]> 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
>
> um. hate to say this, but yes, we did commit to defining a few data
> formats (look at the charter.) i think we said we were going to do
> asset and avatar data formats.
>
> but the MPEG guys are working on a standard avatar format. assuming
> that format is free of IPR encumbrance, i'm totally down with
> considering it as our standard format and then defining it by
> reference.
>
> also, proposals i've seen for the "format" for assets have all been
> resources defined by LLIDL or DSD, so they're extensible and they're a
> little more "abstract" than what we might normally call a "data
> format." (though we do define serializations.)
>
> but we're TOTALLY not going to try to re-invent texture formats, audio
> data format and i'm assuming there are some open animation formats out
> there somewhere.
>
> > 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.
>
> cool. sounds great. i want to support your goal of stitching your
> services together in the way you want to stitch them together as long
> as you support my goal of doing it the way i want to stitch my
> services together.
>
> we're starting to get a little abstract here, let's all keep our heads
> and remember that at some point john and i are going to have to code
> this stuff.
>
> > 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.
>
> yeah. but maybe the thing to do is define a small standard now and
> then try to figure out what's wrong with it as the world changes? you
> have to be careful with how much extensibility you throw into
> something, otherwise you spend all of your time coding for use cases
> that will never emerge.
>
> still.. yeah.. extensibility in general is good.
>
> > 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.
>
> so you're opposed to the "boil the ocean one thimble at a time" approach?
>
> <insert incendiary comment here that leads to a flame war where we
> talk past each other for a couple days then eventually cool down and
> start having rational conversations again>
>
> this sounds like you don't like the idea of starting small,
> standardize what we can all agree to and then move on? is that
> possibly right?
>
> what's wrong with standardizing something, deploying it, figuring out
> what's wrong with it and then trying again if we don't get traction?
>
> > 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.
>
> yes. i've used the example of SIP and SS7. they're protocols that "set
> up" calls but can be used with different specific bearers.
>
> but by the same token, both SIP and SS7 are designed for a relatively
> small, and IMHO underspecified problem domain.
>
> i REALLY don't want VWRAP to become the Advanced Intelligent Network
> initiative of virtual worlds, otherwise it will be useless.
>
> >
> > 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
> >
> >
>