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

Where does process migration fit in?

That could include simple script migration from server to client or from 
server to server. It could include migration from system to subsystem.

Meadhbh Hamrick wrote:
> hey peeps...
>
> so after yesterday's fireworks, i think it's safe to say the group
> agrees we're trying to build standards for "some kind of virtual
> experience." we agree that the group should define "services," to
> simulate the virtual world. and we should define enough services that
> a software developer could take our documents and code something that
> has a good chance of a) interoperating with other software developer's
> output and b) provides a reasonably complete virtual world experience.
> further, i _think_ we agreed there should be no requirement that a
> service deployer should have to deploy ALL the services we define;
> it's up to the individual deployer what services they want to offer.
>
> a lot of people on this list have experience with Linden's Second Life
> Viewer (and similar programs.) i think the experience of a virtual
> world through this program has shaped a lot of people's recent
> opinions of what should and what shouldn't be in a virtual world.
>
> josh bell gave a presentation titled "what's *not* in VWRAP" at last
> spring's IETF face to face in anaheim. you can find the notes here:
> http://www.ietf.org/proceedings/10mar/slides/vwrap-6.pdf [warning,
> PDF.]
>
> to begin the discussion, i'm going to list a few things i think should
> be standardized by this group, then a few things that i think
> shouldn't. please note that i'm all for standardization, it's just
> that for some of these features we may want to rely on what josh
> refers to as "convention" rather than standardization. in other words,
> peeps should definitely develop standards for enough stuff to be able
> to render a virtual world with terrain, objects and avatars, but i
> don't think this group has to standardize everything (like postcards.
> why the heck do postcards go through linden's servers when it's
> EXTREMELY likely that if you have a second life account you also have
> an email account. but i digress.)
>
> so here's my list. i'm not trying to tell people the is the only list
> that would ever work. they're just my thoughts...
>
> * type system - in
>
> i'm a big fan of the abstract type system and it's related
> serialization schemes. i'm not the world's biggest fan of LLIDL. i
> like what it's trying to do, but all that line noise used to define
> resources is annoying.
>
> * authentication - in or out? BOTH
>
> so now that linden has de-emphasized their participation in this
> group, and we probably won't know for a while if they'll ever
> implement anything we specify, why bother with legacy linden
> authentication. their current "legacy" auth goes over XML-RPC which
> IMHO is the internet equivalent of a skin disease that you just can't
> get to go away. it also uses MD5. i can't express my feelings for MD5
> in polite company.
>
> there are some very interesting conversations / arguments going on
> regarding OAuth. it's a well understood authorization technology that
> many of us on the list have used in the past. OpenID is also vaguely
> popular, though i'm not it's biggest fan. i do know that some of the
> .edu peeps are supporting shibboleth which is (correct me if i'm
> wrong) layered on top of SAML.
>
> however... there is one aspect of the current auth spec that is (IMHO)
> "really cool." and that's the part that provisions a seed capability.
> zha and i have bounced up and down about how caps solve some vexing
> problems dealing with loosely coupled collections of services.
>
> also, most current OAuth instances like to direct people to HTML web
> pages. this can be a problem for peeps with desktop  apps. yes, you
> can integrate a web browser with your viewer and capture the final
> redirect. btw, one of linden's problems with this idea was you got
> software distributed by linden that redirects people to web pages
> owned by other people, and this sorta freaks some corporate users out.
>
> so... were i the empress of all the internet, i would decree that
> linden legacy auth and linden OGP auth be deprecated and declare that
> implementers were free to use whatever auth technology they want to
> use to authenticate the user prior to giving them their seed cap. but
> because i was a kind monarch, i would define one or two standard,
> thought non-normative, techniques for using other auth technologies.
>
> so instead of calling this auth, i would go back to calling it
> "service establishment."
>
> * maintenance - IN
>
> if you look at the existing auth spec, there's a resource defined for
> login-time user maintenance. it's pretty straight forward to support
> on the client side, and there's no requirement that you have to use it
> on the server side.
>
> * account properties - some IN, mostly OUT
>
> i think we should have a standard way for a client or service to
> request basic information about a user, an agent or an avatar. but
> honestly, i think a lot of the stuff that get's displayed in the
> Second Life Viewer's profile floater could just as easily be rendered
> as a web page.
>
> * agent / avatar control - IN
>
> yes, we should define a standard set of messages for controlling the
> user's avatar. however, i think we should build an extensible control
> sub-protocol. so maybe we start with messages labeled 'CONTROL-MOVETO'
> to define how the user's
> avatar should be moving around the virtual world. later we may want to
> add 'CONTROL-ANIMATION' for synchronizing an avatar's animation with
> real-life events from the client.
>
> * asset access - IN
>
> there's lotsa fun stuff that's been hypothesized for next generation
> assets. suffice to say, at the very least manipulation of meta-data
> and a way get link objects in user's inventories and objects in world
> with objects in an asset server is "a good thing."
>
> * asset upload - OUT? maybe? IN? kinda
>
> there are plenty of great protocols and data formats for defining
> assets. X3D, COLLADA, etc. and HTTP PUT is well understood. so i don't
> know that we have to create any new protocols for uploading assets.
> but we may want to define a technique by which a user can tell an
> asset server it's wants to upload something and then the asset server
> gives the client a URL to a HTTP PUT resource where it can upload it.
>
> * build tools - OUT
>
> the ability to do "group builds" in second life and OpenSim instances
> is one of the compelling things about those worlds. i think there
> should be a standardized way to do builds "in world." but IMHO, SL
> does it wrong. OpenSim inherited SL's wrongness. we could do it MUCH
> better. but i would recommend we pass on building a standard for it in
> this group.
>
> * communication - some IN, some OUT
>
> anyone who's experienced the "joy" of second life's group chat feature
> can quickly see how it's not up to the task. XMPP is a PERFECTLY GOOD
> chat protocol. however, for spatial chat, you would probably want some
> way to identify a location in the virtual world as the endpoint of a
> chat message, so at the very least we should have enough specification
> for how to represent locations or avatars in the virtual world for
> XMPP or SIMPLE or IRC or whatever chat protocol we would want to use.
>
> but the existing linden legacy protocol chat should definitely be
> deprecated. or caught in a dark alleyway when no one's around and put
> out of it's misery.
>
> * event profiles - OUT
>
> this is something that should be a web page
>
> * friends and groups - OUT? IN?
>
> this is a tough one. groups are kind of an important part of second
> life's social fabric. but i have a hard time justifying a group access
> and management protocol when i know that the first thing a third party
> is going to do is ignore the protocol and implement something that
> talks to twitter or facebook.
>
> but... it is still nice to have some standard way to query a user's
> presence. maybe the thing to do is to define a
> "presence field" in a user or avatar's public profile. you could then
> stuff the URL to your public profile on your facebook page or some
> twitter app somewhere and virtual world clients could "do the right
> thing" by querying your social network on facebook / twitter / avatars
> united / etc, reaping the links to user's public profiles and then
> querying their presence status.
>
> or maybe i should just shut up and go code some examples.
>
> anyway... thoughts?
>
> * parcels - OUT! OUT! A THOUSAND TIMES OUT!
>
> parcels are a linden invention that (IMHO) should not be part of this
> protocol standard. i'm all for lindens making publicly defined
> extensions to describe their parcel system, but i don't think every
> region should be forced to carry this bit of linden baggage.
>
> * land and region profile - IN
>
> on the other hand, it's good to know a thing or two about the virtual
> land upon which your avatar stands (like where to go to get the scene
> graph). that should definitely be in the protocol.
>
> * search - OUT
>
> this should be a web page.
>
> * teleport - IN
>
> * virtual currency - OUT
>
> * world map - OUT
>
> * "space server" - IN
>
> this is the resource that defines the adjacency and shape of various
> regions. i don't think we could have a meaningful virtual world
> experience without it.
>
>
> okay... these are just some ideas to kick-start the conversation. i'm
> interested to hear what other peeps think. if i didn't mention your
> favorite service it was an oversight, not a slight.
>
> -cheers
> -meadhbh
> --
> meadhbh hamrick * it's pronounced "maeve"
> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
>   

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant