AW Groupies/Chat Logs/AWGroupies-2010-05-19

Meadhbh Oh (formerly Infinity Linden) presents a talk with slides (url to be added here) on the topic of "future-proofing VWRAP".

[9:46]	Meadhbh Oh:	okay. so
[9:46]	Meadhbh Oh:	lemme just start
[9:47]	Meadhbh Oh:	so yeah. like latha just said
[9:47]	Meadhbh Oh:	the future... it's coming...
[9:47]	Meadhbh Oh:	we want VWRAP to be compatible with it
[9:48]	Meadhbh Oh:	so this is a talk about what we're doing to try to make sure we don't specify ourselves into a corner
[9:49]	Latha Serevi:	Great topic, Meadhbh
[9:49]	Morgaine Dinova:	Yep, very good topic
[9:49]	Meadhbh Oh:	i think the last bullet point is the most important
[9:49]	Meadhbh Oh:	rather than try to make VWRAP "completely correct"
[9:50]	Meadhbh Oh:	let's buyild a protocol that's extensible
[9:50]	Beyond Baroque:	You're not super-geniuses? I'm so disappointed, think I'll leave now. :D
[9:50]	Meadhbh Oh:	try a bunch of crazy ideas (some of which will turn out to be quite idiotic)
[9:50]	Meadhbh Oh:	and abandon them quickly
[9:51]	Meadhbh Oh:	so here's the big question...
[9:51]	Meadhbh Oh:	how do we make it extensible?
[9:51]	Meadhbh Oh:	don't tell anyone
[9:51]	Meadhbh Oh:	but you can tell people we have some good ideas
[9:51]	Dahlia Trimble:	review question: define interoperability?
[9:51]	Meadhbh Oh:	in terms of VWRAP
[9:51]	Latha Serevi:	Technique 1 for future proofing: "pass through and ignore" certain classes of payload.
[9:52]	Meadhbh Oh:	interoperability means interop between systems that collaborate to simulate the virtual world
[9:52]	Mojito Sorbet:	Pass thryu and ignore anything you do not recognize
[9:52]	Meadhbh Oh:	or "a virtual experience"
[9:52]	Meadhbh Oh:	and not interop between worlds
[9:52]	Meadhbh Oh:	so we're not talking about teleporting from SL to WoW or QWAQ
[9:52]	Mojito Sorbet:	Who do you mean "we"?
[9:53]	Dahlia Trimble:	so nothing to do with "teleporting" between worlds?
[9:53]	Static Melody:	hello
[9:53]	Meadhbh Oh:	and converting their event streams to something that is renderable by SL
[9:53]	Morgaine Dinova:	False. We agreed that we're doing "interop between worlds" in OGPX.
[9:53]	Rex Cronon:	hi
[9:53]	Meadhbh Oh:	"we" being the people who chartered the VWRAP working group
[9:53]	Morgaine Dinova:	It's one deployment, or many
[9:53]	Morgaine Dinova:	Of* many
[9:53]	Latha Serevi:	let's mentally edit "We are not talking about" --> "Meadhbh is talking about"
[9:53]	Meadhbh Oh:	MMOX is still the place to go to discuss ideas for inter-virtual world interop
[9:53]	Zha Ewry:	/,me suggests not having this semantgic sidehosw here
[9:53]	Morgaine Dinova:	Not everyone has to do "interop between worlds", but many will.
[9:54]	Joshua Linden:	we're hitting the "is there one big virtual world made up of many providers or is that multiple worlds you're teleporting between?" semantic question. Does VWRAP aim to specify how you can teleport from SL to an openSim instance? I believe, "yes"
[9:54]	Dahlia Trimble:	ty Joshua
[9:54]	Meadhbh Oh:	so a subset of the people in consensus reality who are thinking about a particular type of virtual world hereafter hypothetically described as "we"
[9:55]	Morgaine Dinova:	MMOX is the place for discurring interop between different types of VWs. VWRAP is the placce for discussing interop between worlds of the general model we call "SL-like".
[9:55]	Latha Serevi 's ears perk up at the MIME type topic on the slide.
[9:55]	Zha Ewry:	And between OpenSIm instances, which may feel very "world" ish. WOrld is remakrbaly NOT a technicsal term of the art
[9:55]	Meadhbh Oh:	have come up with some patterns for dealing with retrofitting protocols to deal with mistakes
[9:55]	Meadhbh Oh:	there are actually two on this slide, but it looks like it got formatted a little funkily
[9:56]	Morgaine Dinova:	Mead: even though this talk is not subject to VWRAP rules, you'd better stick to what we've agreed VWRAP is all about. Stop reinventing things to suit you, long after they've been agreed in the WG.
[9:56]	Latha Serevi:	ooh, patterns.
[9:56]	Beyond Baroque:	This brings up fond old memories of COM programming...
[9:56]	Meadhbh Oh:	the first is the "service establishment pattern"
[9:56]	Meadhbh Oh:	which is the dance of authenticating yourself
[9:56]	Zha Ewry needs an avatar umbrelling, its raining peeps
[9:56]	Meadhbh Oh:	getting a seed pattern
[9:56]	Meadhbh Oh:	er
[9:56]	Meadhbh Oh:	seed capability, i mean
[9:56]	Rand Brune:	hi all
[9:56]	Meadhbh Oh:	then requesting child caps from the seed
[9:57]	Meadhbh Oh:	the second is the "estensible message pattern"
[9:57]	Meadhbh Oh:	or even extensible
[9:57]	Meadhbh Oh:	so let's examine the service establishment pattern first
[9:57]	Meadhbh Oh:	note the skillful use of the term "agent domain" intended to drive zha crazy
[9:58]	Meadhbh Oh:	so...we start with a client that wants to get the URL to a resource on a remote system
[9:58]	Meadhbh Oh:	lemme advance the slide first
[9:59]	Meadhbh Oh:	on the left you have your client
[9:59]	Meadhbh Oh:	on the right you have your server
[9:59]	Meadhbh Oh:	the dark boxes in the middle represent sub-protocols understood by both
[9:59]	Dahlia Trimble:	the revisions refer to protocol revisions?
[9:59]	Meadhbh Oh:	if you look carefully, you'll see there's some overlap
[10:00]	Paradox Olbers is Offline
[10:00]	Meadhbh Oh:	but there's not an exact match
[10:00]	Meadhbh Oh:	we thikn this is going to be VERY common in the future
[10:00]	Imaze Rhiano:	cool avatar Dahlia
[10:00]	Dahlia Trimble:	ty :)
[10:00]	Tapple Gao:	lots more tinies here than usual
[10:01]	Meadhbh Oh:	where you have a lot of people who's client's grok a revision of a protocol that's different from other clients
[10:01]	Meadhbh Oh:	and may be different from many servers
[10:01]	Latha Serevi:	good premise.
[10:01]	Meadhbh Oh:	so the first thing we want to do is figure out what sub protocol to use
[10:02]	Meadhbh Oh:	so the client authenticates and then basically sais
[10:02]	Meadhbh Oh:	"hey, here are the revisions of sub-protocols i understand. you cool with any of these?"
[10:02]	Dennis CiscoSystems is Offline
[10:02]	Meadhbh Oh:	and then the server figures out which ones it likes
[10:03]	Meadhbh Oh:	and sends back URLs for each of the ervices it likes (from the list given it by the client)
[10:03]	Joshua Linden:	Meadhbh: do you envision the revisions are actual version numbers, "just part of the name", or both, or ...? i.e. can you reason that "teleport rev 3" is a superset of "teleport rev 2" ?
[10:03]	Meadhbh Oh:	there are probably advantages for both
[10:04]	Meadhbh Oh:	we could identify subprotocols by number or by a distinct string
[10:04]	Latha Serevi:	Does this description of the pattern correspond to any particular VWRAP drafts, or is it something we'd hope to draft later?
[10:04]	Meadhbh Oh:	hmm... lemme see if i can dig up the url for this presentation
[10:05]	Meadhbh Oh:	latha. it's described in the intro and in the auth drafts
[10:05]	Meadhbh Oh:	i think the auth draft needs to be a little more explicit about it though
[10:06]	Meadhbh Oh:	but this was one of those things where we initally were saying.. "ye gads, let's not FORCE people to do it this way, just standardize a way for people to do it like this."
[10:06]	Meadhbh Oh:	though honestly
[10:06]	Meadhbh Oh:	we didn't really describe what we were envisioning especially well
[10:07]	Meadhbh Oh:	quick review
[10:07]	Meadhbh Oh:	we end up with a list of services the client and the server agree to use
[10:08]	Meadhbh Oh:	and here's the big downside
[10:08]	Latha Serevi:	Will the client provide a list of protocols in preference order, and then the server pick the one it can handle that's highest on the list? Or can it pick one the client doesn't like very much because the server likes it better? :-o
[10:08]	Imaze Rhiano:	can client ask more services later on?
[10:08]	Meadhbh Oh:	viewer developers have to cope with the situation of dealing with servers that speak some other version of a protocol
[10:08]	Meadhbh Oh:	lmaze. there's been some debate about that
[10:09]	Meadhbh Oh:	essentially yes
[10:09]	Meadhbh Oh:	there's debate on whether you have to reauthenticate to do it
[10:09]	Meadhbh Oh:	but yeha. that's an important use case
[10:10]	Meadhbh Oh:	like you start your morning by logging in ONLY to participate in a group chat session
[10:10]	Meadhbh Oh:	and then later on, you want to look at your inventory
[10:10]	Meadhbh Oh:	and then later on you want to go in world
[10:10]	eighthdwarf Checchinato:	o.0
[10:10]	Zha Ewry:	Not that some of this links into what JOsh was talking about (adding new functoins picking them up)
[10:10]	Zha Ewry:	and into some of the client side caps stuff I've been describving
[10:10]	Meadhbh Oh:	fwiw. linden's been doing this for a while
[10:11]	Imaze Rhiano:	I was just thinking that client needs service A - but if service A is not available client can also use service B - so - currently best way to handle situtation is to ask both services A and B - in case if service A is not available
[10:11]	Meadhbh Oh:	(or a version of this)
[10:11]	Zha Ewry:	Since, effecvtively, we;'re at the point of wiring this stuff together
[10:11]	Zha Ewry:	*note
[10:11]	Meadhbh Oh:	+1 lmaze
[10:11]	Meadhbh Oh:	maybe we should add a "preferences" field to the startup message
[10:12]	Meadhbh Oh:	that says, "i know how to do a and b, but prefer b"
[10:12]	Meadhbh Oh:	but yeah. linden's been doing this a while
[10:12]	Gazanfer Jehangir:	what guarantees the authenticity and credibilty of a service thats enables externally
[10:12]	Static Melody:	yes, for both client and server
[10:13]	Meadhbh Oh:	but mostly when dealing with CAP based services that replicate services offered by the old UDP system
[10:13]	Zha Ewry:	We also want to, as much as possible not get terribly far from web practices.
[10:13]	Meadhbh Oh:	+1 zha
[10:13]	Meadhbh Oh:	we're not a web app
[10:13]	eighthdwarf Checchinato:	exactly
[10:13]	Meadhbh Oh:	but there's a lot of deployment wisdom in the way the web evolved
[10:13]	Meadhbh Oh:	okay. lemme move on to the next pattern
[10:13]	Zha Ewry:	Mind you, Upgrade is honored in the breech, or I'd half suggest that.
[10:13]	Susan Tsuki:	and REST is preferable to roll-your-own
[10:13]	Meadhbh Oh:	unless peeps wanna talk more about this one?
[10:14]	Zha Ewry:	Onwardds, very black clad Mea
[10:14]	metaPRESENTER: Thanks, You Will Receive your metaHUD shortly. Enjoy...
[10:14]	Meadhbh Oh:	so here's a quick example of how you might want to enhance an API
[10:15]	Meadhbh Oh:	in rev n, you get to associate an image URL with a description
[10:15]	Meadhbh Oh:	but in rv n+1, you want to add more info (like the location in SL where the image was captured)
[10:15]	Meadhbh Oh:	actually
[10:16]	Meadhbh Oh:	let's look at the XML while i gab about why this is a good way to do it
[10:16]	Susan Tsuki:	excuse me, but am I the only one whose sensibilities are deeply offended byt <integer>20</integer> two dozen bytes for how many bits?
[10:16]	Meadhbh Oh:	we could have created a message with fixed length strings
[10:16]	Meadhbh Oh:	susan. there's an app for that
[10:16]	Latha Serevi:	btw, usage of "key-value pairs" is basic good future-proofing practice. ++
[10:16]	Meadhbh Oh:	i'm using XML here to demonstrate a feature of the message
[10:17]	Meadhbh Oh:	if sending a compressed XML or JSON fragment is too much overhead, there's a binary encoding that's more efficient
[10:17]	Saijanai Kuhn:	JSON is an acceptable alternative
[10:17]	Saijanai Kuhn:	or binary
[10:17]	Meadhbh Oh:	so yeah. if we had fixed length fields
[10:18]	Meadhbh Oh:	we would have to have way different parsers for rev n and rev n+1
[10:18]	Morgaine Dinova:	Susan: if it required live marshalling/demarshalling at high rates, then yes, you'd be right to be offended on efficiency grounds. :-) But hopefully we're not going to be using this serialization for high-speed object updates, only for slow-rate command traffic across the REST interface.
[10:18]	Susan Tsuki prefers JSON
[10:18]	Zha Ewry looks for her "Veteren of the angle bracket wars" tee shirt.
[10:18]	Meadhbh Oh:	lol
[10:18]	Zha Ewry really ought to make that one up both for SL and RL.
[10:18]	Meadhbh Oh:	you really don't want to know what i prefer
[10:18]	Meadhbh Oh:	but anyway
[10:19]	Meadhbh Oh:	we put our message in an extensible map
[10:19]	Susan Tsuki:	xml made utf-8 pervasive and for that I am appreciative. But it's time to do better
[10:19]	Meadhbh Oh:	hwere the interesting values are key-value pairs
[10:19]	Meadhbh Oh:	adding the new fields to the map was pretty simple
[10:19]	Zha Ewry gently suggests fixing the web's fetsish for XML encoding is out fo scope
[10:20]	Meadhbh Oh:	you just add a new key
[10:20]	Goldie Katsu agrees with Zha
[10:20]	Meadhbh Oh:	and
[10:20]	Meadhbh Oh:	(you're going to hate this)
[10:20]	Morgaine Dinova:	Goldie!!!!! Welcome back, stranger :-))
[10:20]	Meadhbh Oh:	you access the values using something akin to
[10:20]	Meadhbh Oh:	document.getElementById("title")
[10:20]	Shamir Katsu laughs
[10:20]	Meadhbh Oh:	it's not exactly the same, of course
[10:21]	Meadhbh Oh:	but the way that client libraries are being implemented
[10:21]	Goldie Katsu gives a shy wave and says "hi!"
[10:21]	Morgaine Dinova:	:-)
[10:21]	Meadhbh Oh:	it's rather like accessing the element of a map
[10:22]	Meadhbh Oh:	okay.more important things going on...
[10:22]	Frans Charming:	/Hi Goldie!
[10:22]	Meadhbh Oh:	if a rev n+1 message is encountered by a rev n service
[10:22]	Dahlia Trimble:	libomv has a pretty good api for it
[10:22]	Meadhbh Oh:	it will just ignore the extra bits
[10:22]	Meadhbh Oh:	if a rev n message is encountered by a rev n+1 service,
[10:23]	Meadhbh Oh:	it's developers will probably know they're a rev n+1 implementation and will know not to freak out if the extra bits raen't thereOnline
[10:24]	Meadhbh Oh:	the main downside is you hvae to be VERY, VERY careful you don't change the semantics of messages between revisions
[10:24]	Zha Ewry:	That's always a chalange
[10:24]	Meadhbh Oh:	i mean no offense to my former co-workers
[10:24]	Meadhbh Oh:	but
[10:24]	Zha Ewry:	Versinoing, at somep oint, you need to simply change the nameof the UI
[10:24]	Anya Silbermann is Online
[10:25]	Zha Ewry:	"This is not longer compatible, calling it "telepotrt" would be bad, lets calli t "teleport v2"
[10:25]	Meadhbh Oh:	i am convinced that if some of them were tasked with developing a nuclear missle launch protocol, they would start with the flickr API
[10:25]	Zha Ewry:	Well, you send the code keys as a set of flikr images
[10:25]	Meadhbh Oh:	rught zha
[10:25]	Meadhbh Oh:	s/rught/right/
[10:25]	Zha Ewry:	then you use oauth to create a key...
[10:25]	Meadhbh Oh:	yay! we don't break reverse compatibility
[10:26]	Meadhbh Oh:	so there are some more patterns
[10:26]	Meadhbh Oh:	but
[10:26]	Meadhbh Oh:	we've been going at it for close to an hour
[10:26]	Meadhbh Oh:	wanna press on
[10:26]	Meadhbh Oh:	?
[10:26]	Latha Serevi:	yes please, keen on MIME topic
[10:26]	Zha Ewry:	mush mush
[10:26]	Zha Ewry:	Oh, no wait, that's Latha
[10:26]	Meadhbh Oh:	kk
[10:26]	Zha Ewry:	Onwards, in any case
[10:26]	Imaze Rhiano:	hour? I did come here half hour ago... :(
[10:27]	metaPRESENTER: Thanks, You Will Receive your metaHUD shortly. Enjoy...
[10:27]	metaPRESENTER: Thanks, You Will Receive your metaHUD shortly. Enjoy...
[10:27]	Zha Ewry:	It took us half an hour to get the show under way
[10:27]	Meadhbh Oh:	sothere are reasons people like HTTP
[10:27]	Meadhbh Oh:	we're using two big features of HTTP
[10:27]	Meadhbh Oh:	redirects
[10:27]	Meadhbh Oh:	and
[10:27]	Meadhbh Oh:	URLs
[10:28]	Susan Tsuki:	I have a question: why is a teleport even a server-to-server operation? People complain about server-to-server referrer http headers when they click hyperlinks. Why isn't teleporting strictly server-to-client-to-server?
[10:28]	Meadhbh Oh:	because we like to have the agent's avatar in exactly one place
[10:29]	Susan Tsuki:	well I like to be in two places at the same time
[10:29]	Jennette Forager is Offline
[10:29]	Meadhbh Oh:	well. it's sort of out of scope for VWRAP
[10:29]	Imaze Rhiano:	alt tabbing virtual locations? :P
[10:29]	Susan Tsuki:	I respectfully disagree
[10:29]	Dahlia Trimble:	having the avatar in one place doesnt seem to be something everyone would want
[10:29]	Gazanfer Jehangir:	just as i said
[10:29]	Zha Ewry:	Its effectivlly a transactoin between the two regoins. Adding an untrustable third party component makes it into a challange
[10:29]	Gazanfer Jehangir:	security..
[10:30]	Meadhbh Oh:	well. actually it DOES mention the "you're in one place at a time" thing in the charter
[10:30]	Muse Carmona:	someone has an open mic
[10:30]	Meadhbh Oh:	and in the intro
[10:30]	Morgaine Dinova:	Susan: there's strict separation between agent policies and region policies. The Agent Domain is involved because it may want to refuse you permission to go to some region. If it has allowed you though, then it takes no further part in region policy decisions. So it's a mixture of both S-S and S-C-S.
[10:30]	Joshua Linden:	Susan: that's come up in discussion before. In addition to what Meadhbh said, that might be the general-case fallback, in some cases (download all agent state and disconnect, connect and upload agent state) but that download/upload may be extensive. There are also permission checks , yadda yadda. Again, in a pure tourism mode where either everything is fully trusted or untrusted, it may not make a difference.
[10:30]	Meadhbh Oh:	we're boiling a small portion of the ocean right now
[10:30]	Dahlia Trimble:	I'm not sure why it's a necessity to have it in one place only
[10:31]	Meadhbh Oh:	when it's hot, we'll loop back around and boil the multiple avatar locations part of the ocean
[10:31]	Zha Ewry:	(Actually the one ave at a time, many ave at a time questoin is mostly orthonoganl between whether the clienbt gets in the fance when you tp
[10:31]	Zha Ewry waves at Goldies Dog
[10:31]	Meadhbh Oh:	okay. let's table that discussion for the moment
[10:31]	Muse Carmona:	zha - fance?
[10:31]	Meadhbh Oh:	so
[10:31]	Zha Ewry:	*dance
[10:31]	Muse Carmona:	what's that typonese for?
[10:31]	Zha Ewry cannot type tonight
[10:31]	Muse Carmona:	zha ewry doesn't know what time it is :-)
[10:31]	Meadhbh Oh:	so... redirects
[10:32]	Joshua Linden:	Goldie, open mic?
[10:32]	Meadhbh Oh:	they're nice because you can move a resource from one server to another
[10:32]	Zha Ewry:	Whether you allow multiple aves on at once, you still end up with the trust issue if you injhect the client into a tp
[10:32]	Susan Tsuki:	I'm thinking about the practicalities of trying to bridge SL with cobalt, which I presume is in scope. I think we need to start with the Cobalt idea of interconnected peers.
[10:32]	Gazanfer Jehangir:	also how does the server know that perhaps your account has been compromised
[10:32]	Gazanfer Jehangir:	so again securuty
[10:32]	Meadhbh Oh:	susan. that's out of scope for VWRAP
[10:32]	Dahlia Trimble:	I can see it being useful for teleporting, but there may be other times when having multiple avatars would be desirable
[10:33]	Susan Tsuki:	why?
[10:33]	Muse Carmona:	bots.
[10:33]	Zha Ewry:	B ecause when we tried to charter MMOX, the cmmunity blew up on the model to do so
[10:33]	Muse Carmona:	building alts, testing alts
[10:33]	Joshua Linden:	Susan: The charter is here: http://tools.ietf.org/wg/vwrap/charters
[10:33]	Morgaine Dinova:	Susan: it's in scope if you can create a VWRAP interface or gateway for Cobalt, regardless of what Meadhbh says. We're defining a protocol, not tellinh you how to use it.
[10:33]	Muse Carmona:	in general if you don't want people to know "you're online"
[10:34]	Joshua Linden:	We do not deny it is an interesting scenario. It is just not our focus, which was intentionally reduced in order to make progress.
[10:34]	Meadhbh Oh:	so the other bit of HTTP we like is the frequent use of URLs
[10:34]	Zha Ewry:	There were about three attempts to get beyond the "LIke SL" cluster of worlds and we scoped down to what we can do
[10:34]	Susan Tsuki:	Joshua: is there anything in the charter which places Cobalt out of scope?
[10:34]	Meadhbh Oh:	since we drank the REST cool-aid
[10:34]	Gazanfer Jehangir:	may i know where is the webpresence to study this protocol at leisure
[10:34]	Zha Ewry:	Yes, "Second Life LIke"
[10:34]	Joshua Linden:	Susan: read the charter, in light with Morgaine's comment above (which I +1)
[10:34]	Morgaine Dinova:	The only requirement is being able to use the protocol, nothing else. Ie. "VWRAP-compliance".
[10:34]	Susan Tsuki:	I am looking at it. What puts Cobalt out of scope?
[10:34]	Latha Serevi:	Susan, Meadhbh insists lots of things are out of VWRAP scope, that are clearly groupies-scope, so I try not to worry about it too much.
[10:35]	Dahlia Trimble:	I often maintain simultaneous presences with the name "Dahlia Trimble" on various grids and standalone sims
[10:35]	Meadhbh Oh:	if you remember the service establishment dance
[10:35]	Saijanai Kuhn:	Cobalt-SL interop onthe level of a specific client wouldn't be impossible. You just treat incoming SL stuff as part of the external media layer which happens to be 3D objects instead of projections on a screen
[10:35]	Meadhbh Oh:	you have a seed capability
[10:35]	Saijanai Kuhn:	likewise, you translate the cobalt internal stuff into SL scene graph info. Not true itnerop, but would "look like it"
[10:35]	Meadhbh Oh:	and from that capability you get other capabilities
[10:35]	Meadhbh Oh:	that are essentially URLs
[10:36]	Meadhbh Oh:	that can be used to access resources that represent the state of the virtual world
[10:36]	Meadhbh Oh:	so in a stand-alone sim
[10:36]	Meadhbh Oh:	the seed cap and all the subordinate caps
[10:36]	Meadhbh Oh:	are on the same host
[10:36]	Susan Tsuki:	Zha: the words "Second Life" don't appear in the charter, were you being serious?
[10:36]	Meadhbh Oh:	so the URLs to them will all start with
[10:37]	Meadhbh Oh:	http://www.whatever.com/
[10:37]	Meadhbh Oh:	hmm... bad example
[10:37]	Meadhbh Oh:	let's just say they all point to the same machine
[10:37]	Latha Serevi:	what-everrrr.
[10:37]	Meadhbh Oh:	in a private grid
[10:37]	Meadhbh Oh:	the subordinate capabilities
[10:37]	Meadhbh Oh:	(those are the caps you get from querying the seed cap)
[10:38]	Meadhbh Oh:	may point to different machines
[10:38]	Meadhbh Oh:	but they're probably going to be in the same domain
[10:38]	Meadhbh Oh:	and in a more open grid model
[10:38]	Meadhbh Oh:	you have subordinate caps that point all over the place
[10:39]	Meadhbh Oh:	but an important thing to note here
[10:39]	Susan Tsuki:	Joshua: I have read every word. Why would you say it excludes Cobalt?
[10:39]	Meadhbh Oh:	it's the agent domain that gives you the subordinate cap
[10:39]	Morgaine Dinova:	Joshua didn't say that, Susan. :-)
[10:39]	Meadhbh Oh:	kk da5id
[10:39]	Meadhbh Oh:	i'll ping the list with the URL to the goodle presentation
[10:39]	Meadhbh Oh:	s/goodle/google/
[10:39]	Joshua Linden:	I would not say it excludes Cobalt. It is simply not a focus.
[10:40]	Morgaine Dinova nods
[10:40]	Meadhbh Oh:	i would say it exclides Cobalt because one of cobalt's core features is that it eschews a standard wire protocol in favor of running a bit identical image on multiple hosts
[10:41]	Meadhbh Oh:	cobalt also uses a peer-to-peer model
[10:41]	Joshua Linden:	If you go off and implement cobalt/opensim interop, no-one participating in the VWRAP group would say that's a bad idea. It's just that the work wouldn't necessarily fall under the charter .
[10:41]	Susan Tsuki:	Why isn't it a focus? Do you mean a focus for this talk, a focus for vwrap, or is there a focus document parallel to the charter?
[10:41]	Morgaine Dinova:	Susan: VWRAP hasn't yet tackled trying to define exactly what "VWRAP-compliance" means. It's roughly "being of the SL and Opensim model", but the protocol will probably need to get filled in a lot before we can be more precise. But any world that can develope a gateway or interface to the protocol can of course us it. No exceptions.
[10:41]	Meadhbh Oh:	when we were doing croquet, we weren't worried about interop with SL
[10:41]	Saijanai Kuhn:	susan, Tapple is a member of the Cobalt development team. Why dodn't you ask him what the issues would be for Cobalt to interact with SL-like worlds in a SL-like way
[10:41]	Joshua Linden will shut up and let Meadhbh continue with the preso
[10:41]	Zha Ewry:	The people who got to consensus on the charter scoped a managable chunk of work (which is bigger than we are effticvely doing)
[10:41]	Meadhbh Oh:	blah blah blah. better example
[10:42]	Zha Ewry:	If people want to a) do work on the issues which would make it more tractable
[10:42]	Meadhbh Oh:	we sort of think that the VWRAP "ecosystem" will look something like this
[10:42]	Zha Ewry:	and b) show us how it fits in and advances the swamped work load
[10:42]	Zha Ewry:	then... its easy enough to make that happen
[10:42]	Meadhbh Oh:	where you've got a couple auth servers out there
[10:42]	Imaze Rhiano:	so... can this model hold situtation where we would have multiple instances of same services - like multiple assets services (region asset service, grid assets service, client side asset service, etc... ) and multiple chats (for example special chat service for group that very active)?
[10:42]	Zha Ewry:	ie. big ocan, chose to boil small ponds
[10:42]	Meadhbh Oh:	(maybe hosted by google, wtitter, facebook, yahoo!, etc.)
[10:42]	Susan Tsuki:	Sai, I think Tapple left ?
[10:43]	Saijanai Kuhn:	guess he did
[10:43]	Meadhbh Oh:	and then some more VWish service
[10:43]	Zha Ewry:	Those who wish to to help boil more water, are welcome to help
[10:43]	Anya Silbermann is Offline
[10:43]	Saijanai Kuhn:	THough, I sit in on the Cobalt developer meetings as the "SL-Cobalt interop guy" so...
[10:43]	Dahlia Trimble:	those are multiple services? i.e., not all controlled by the same business interests?
[10:43]	Muse Carmona:	Susan, from what i understand, vwrIdeally, we need an implementer interested in Cobalt to actively contribute to VWRAP, both in terms of creating an implementation and then giving constructive feedback to the group.
[10:43]	Morgaine Dinova:	Susan: think of VWRAP like SMTP. SMTP doesn't say how MTAs or MUAs have to be structured. Anything that can use SMTP is perfectly fine to use the protocol. Likewise with VWRAP, and indeed with all IETF protocols.
[10:43]	Joshua Linden:	Imaze: ideally, the client is only ever given a (mostly) opaque URL to use for a service. So if it gets the URL for a chat service, it shouldn't care if that URL points to a host that's dedicated for an ubergroup or one that's shared.
[10:43]	Muse Carmona:	does that make sense?
[10:44]	Meadhbh Oh:	the "VWRAP ecosystem" is (IMHO) about exposing interfaces to existing services and make them consumable by virtual worlds
[10:44]	Goldie Katsu wonders if freezing water would be more effective
[10:44]	Muse Carmona:	if someone wants to implement & contribute who is a Cobalt expert, then we can put it in scope
[10:44]	Zha Ewry:	Note entirely, Getting cobalt to fit into the VWRAP model woudl require a lot of new stuff
[10:44]	Zha Ewry:	*not
[10:44]	Zha Ewry:	sheeesh
[10:44]	Muse Carmona:	if not, it's not something we can volunteer to do
[10:44]	Meadhbh Oh:	so here's he big takeaway
[10:44]	Zha Ewry slaps her fingers
[10:44]	Joshua Linden:	("mostly" because for security reasons, pipelining, etc etc, the client may want to reason about the URL)
[10:44]	Meadhbh Oh:	we have a bunch of patterns we think will serve us wel
[10:44]	Meadhbh Oh:	well
[10:44]	Meadhbh Oh:	we're going to make mistakes
[10:45]	Zha Ewry:	The scope is biased by the people who are doing the work, more people, more work, more ability to take on more work
[10:45]	Latha Serevi:	did we miss MIME? My big question was waiting for that slide.
[10:45]	Meadhbh Oh:	many of us have a preference for the "fail quick and move on" model
[10:45]	Morgaine Dinova:	I second Latha's interest.
[10:45]	Susan Tsuki:	well I have a copy of cobalt on my machine, Sai is the designated SL-Cobalt interop guy, and nobody has indicated why the charter puts it out of scope or where the "focus" was decided
[10:45]	Meadhbh Oh:	hmm. yes. i think the MIME discussion was buried in there somewhere
[10:45]	Meadhbh Oh:	as a bullet point on a single slide
[10:45]	Latha Serevi:	May I have the floor for a few minutes at some point?
[10:46]	Meadhbh Oh:	sure
[10:46]	Zha Ewry:	siure, Latha
[10:46]	Zha Ewry:	Well, the grass
[10:46]	Latha Serevi:	I'll chat-splat my issue here, it's not TOO long.
[10:46]	Zha Ewry:	we're rather short on floor
[10:46]	Latha Serevi:	There's a future-proofing-VWRAP issue that seems pretty major that I'm struggling with. ??? It was motivated by Josh's talk on what to leave out of VWRAP. ??? ??? The question is, when something is "out", how can we provide a future-friendly hook to whatever other standard or technique will be used. ??? ??? Josh seemed to suggest "human-readable URL" as the basic kind of hook, but to me it's a big mistake to require a human at any point in a VWRAP interaction. ??? ??? My thought is, having a URI as a placeholder for a function that we are naming-but-leaving-out, is ok, but we want to make sure that a pair of interacting entities that want to use protocol XYZ for dealing with that function, can tell each other that smoothly. ??? ??? So, a pair of "URI plus content-type", or some kind of content-negotiation? ??? ??? It aalso occurs to me that there could be multiple kinds of "out" -- "out but we know what its name and purpose is", and "new capability we never even heard of". We'd want to provide a smooth path for participants to negotiate an intera
[10:46]	Latha Serevi:	ction in both cases.
[10:46]	Saijanai Kuhn:	Susan, its a matter of priorities for the various people involved. The Cobalt team is trying to bring out their official 1.0 release. Interop with SL and OpenSIm is WAAAAAY low on their list of priorities
[10:47]	Joshua Linden:	Good question, Latha. Here's how I'd address it:
[10:47]	Muse Carmona:	I need to go, everyone, RL calls. Thank you for a spirited conversation, see you soon!
[10:47]	Zha Ewry:	Latha, peek on the mailing list, because I raised that about 2 weeks back after JOsh's presentation
[10:47]	Saijanai Kuhn:	likewise, most participants in VWRAP are interested in the lower hanging fruit like getting OpenSim realXtend and SL to work with VWRAP
[10:47]	Joshua Linden:	Let's say we deploy a hypothetical baseline VWRAP client/server. The client knows nothing about land properties (say, modifing parcel permissions) except that when you click on land it is given a tuple of ("parcel_properties_page", "text/html", "http://sim1234.yourgrid.net/someregionid/someparcelid/properties"), and that URL is an HTML page which lets you view and/or edit properties, which is enough for a generic HTML client that embeds a web client like WebKit to present that UI.
[10:47]	Joshua Linden:	(Issues about advertisement of the service and authentical authentication need to be resolved, Zha's been thinking about that.)
[10:47]	Meadhbh Oh:	cheers, muse
[10:47]	Joshua Linden:	Now, let's say that this HTML UI isn't satisfactory - say, you're a power user and want to edit using either more elaborate UI or actually modify a the equivalent of the parcel's ACL file in a text editor. Both experiences could be implemented in HTML, but it may be that the service provider doesn't offer that, but does want to cater to these crowds by engineering multiple interfaces.
[10:47]	Joshua Linden:	I can think of several ways to provide this:
[10:48]	Morgaine Dinova:	I raised during Joshua's talk whether he was advocating web screen scraping as an interop technique. I believe he said "No" (being a rational person :P). So no danger of that, Latha, I think :-)
[10:48]	Joshua Linden:	(1) Treat the initial advertisement of the service availability as capability grants just like at the start of Meadhbh's presentation, and deliver: [("parcel_properties_page", "text/html", "http://sim1234.yourgrid.net/someregionid/someparcelid/properties"), ("parcel_properties_ws", "application/xml", "http://sim1234.yourgrid.net/someregionid/someparcelid/properties_web_service")] where the service is SOAP or REST or XMLRPC or whatever floats your boat. Clients that understand it can use it, clients that
[10:48]	Joshua Linden:	don't fall back to the HTML UI.
[10:48]	Joshua Linden:	(I believe this is your suggestion)
[10:48]	Joshua Linden:	(2) Use HTTP content negotiation, i.e. send an Accept header when making the properties request, e.g. "Accept: text/html, application/x-vwrap-parcel-acl" and define that MIME type as a payload. There are implications that the URL allows RESTful behavior, but I think that's reasonable.
[10:48]	Joshua Linden:	(3) Embed the content as an "upgrade" within the HTML content, e.g. <link rel="webservice" type="application/x-vwrap-ws" href="http://sim1234.yourgrid.net/someregionid/someparcelid/ws">
[10:48]	Joshua Linden:	In any of these cases, you're claiming elements within a namespace, which could be done either vendor-specific (say, Linden wants to offer a premier experience for our client on our grid, we'd use a "vnd.lindenlab." prefix or something), or in a neutral way with the eventual goal of registering with IANA. VWRAP RFCs for this can ask IANA to establish registries for this sort of field.
[10:48]	Joshua Linden:	Some of these are very Web-like, others less so. Your suggest of URI+content-type is a good one. I prefer #1 myself, which aligns best with the other common VWRAP patterns Meadhbh was discussing.
[10:49]	Meadhbh Oh:	or you could even do a redirect based on the user agent
[10:49]	Imaze Rhiano wonders how Joshua manages to write so fast...
[10:49]	Latha Serevi:	Can you guess that I prompted Josh earlier? :-o
[10:49]	Meadhbh Oh:	redirecting web clients to a HTML page
[10:49]	Meadhbh Oh:	but that's ugly
[10:49]	Zha Ewry:	Note that there are really about three issues
[10:49]	Meadhbh Oh:	i agree.. i like #1 too
[10:50]	Susan Tsuki:	Sai: you better claim the elements you want in the namespace early or compatibility will be much harder later
[10:50]	Joshua Linden:	Actually, I mangled the #1 a bit as a result of editing...
[10:50]	Meadhbh Oh:	but that may simply be that we used to be co-workers
[10:50]	Joshua Linden:	It's probably a map from name to tuple of type/URL
[10:50]	Zha Ewry:	ROughly, how to cue
[10:50]	Morgaine Dinova:	Perhaps this is a good opportunity to lay the dragon to rest (again). Joshua: you're not advocating web page scraping as an interface technique, right?
[10:50]	Zha Ewry:	how to let servers help to UI, and how to let servers expose structured apis which are optional
[10:50]	Meadhbh Oh:	but honestly, we could try a couple different things
[10:50]	Joshua Linden:	{ "parcel_properties": [("text/html", "http://blahblah"), ("text/xml", "...")]} - but done LLSD-style
[10:51]	Joshua Linden:	Morgaine: of course not! Well, people will do crazy stuff...
[10:51]	Joshua Linden:	I thought of this scenario:
[10:51]	Morgaine Dinova:	Joshua: :DDDDD
[10:51]	Zha Ewry:	RIght, screen scrpaing HTML is painful to evben think about
[10:51]	Aurora Kitaj is Offline
[10:51]	Zha Ewry:	at the same time
[10:51]	Saijanai Kuhn:	Susan.. 1) Smalltalk doesn't really have namespaces. 2) Croquet is designed in such a different way than VWRAP-ish worlds that "interop" really can't mean what it means for interop between OpenSim and SL
[10:51]	Joshua Linden:	Say I'm using VWRAP implementation pieces to implement a kid-friendly VW (and don't even care about interop)
[10:51]	Meadhbh Oh:	i think the take-away from josh's talk is "not everything in the client will be standardized in VWRAP"
[10:51]	Zha Ewry:	Making the client do a UI when the server can
[10:52]	Zha Ewry:	is also painful. (ie only an API, with no way to allow the sevrer to host a UI)
[10:52]	Joshua Linden:	I might make "parcel properties" UI in HTML as a set of your friend's avatar icons with checkboxes. Totally custom UI.
[10:52]	Susan Tsuki:	namespace:protocol::dictionary:smalltalk
[10:52]	Joshua Linden:	And I have no desire to expose a data API for it.
[10:52]	Saijanai Kuhn:	at the best, you could "fake it" so that it would look like interop but it would require all sorts of translation mechanismis
[10:52]	Meadhbh Oh:	and
[10:52]	Joshua Linden:	IMHO, that would be possible with what we're discussing.
[10:52]	Meadhbh Oh:	you could build your HTML UI
[10:52]	Meadhbh Oh:	so there's some sort of data UI hidden behind it
[10:52]	Susan Tsuki:	"fake it"+marketing department="compatibility layer"
[10:53]	Joshua Linden:	Now, some crazy person might want to screen-scrape that, but that's outside the scenario the VWRAP WG or the service provider are designing for
[10:53]	Saijanai Kuhn:	Susan, sure, but its a very THICK layer in this case
[10:53]	Susan Tsuki is not so sure
[10:53]	Zha Ewry:	I am not putting MY name on a screen scarping HTML designn ;)
[10:53]	Latha Serevi:	Josh, I'm with you on the kid VW. But if Kid VW version 2 decides to provide the data API after all, we want them to know that they can add a content-type...
[10:53]	Morgaine Dinova:	+1 Zha
[10:53]	Joshua Linden:	I would prefer that people do expose data APIs for things, but IMHO VWRAP shouldn't mandate that or be blocked until we have defined all of those APIs
[10:54]	Zha Ewry:	+1 Joshua
[10:54]	Meadhbh Oh:	so let's not do HTML screen scraping for things that are core
[10:54]	Zha Ewry:	and.. I think our repsonsibility ends at the
[10:54]	Zha Ewry:	"here is the mechanism"
[10:54]	Joshua Linden:	Latha: agreed, so we need to define that mechanism. +1 Zha
[10:54]	Zha Ewry:	"you go define the specific services you need"
[10:54]	Saijanai Kuhn:	Susan SL and other worlds with a hope of being VWRAP compatible directly, use a data distribution method. Cobalt sends smalltalk object messages
[10:54]	Zha Ewry:	We cue you the service is around
[10:54]	Meadhbh Oh:	ack! i have to leave soonish
[10:55]	Zha Ewry:	we provide both UI (webish) hooks and API (Service hooks) in a nice way, and if people biuld stuff out, we're done
[10:55]	Zha Ewry:	(and there is, al lurking how it ties to the scenegraph questoin, since this stuff all is part of th VW expeience)
[10:55]	Meadhbh Oh:	i'm going to run off and dig up the URL to this presentation and email it to sldev and vwrap@ietf.org
[10:55]	Joshua Linden:	Thanks, Meadhbh
[10:55]	Meadhbh Oh:	cheers folks
[10:55]	Perplexity Peccable:	thanks!
[10:55]	Zha Ewry:	Thanks Mea
[10:55]	Susan Tsuki:	what does "kid friendly" mean? http://www.ncbi.nlm.nih.gov/pubmed/19665229
[10:55]	Saijanai Kuhn:	Thanks Meadhbh
[10:55]	Meadhbh Oh:	do we want to do follow-on conversations in vwrap@ietf.org
[10:56]	eighthdwarf Checchinato:	Thank you very much Meadhbh
[10:56]	Meadhbh Oh:	i think there are plenty of good ideas floating around
[10:56]	Zha Ewry:	Yes, on vwrap
[10:56]	Zha Ewry:	but if so, keep in mind, its NOTEWELL land
[10:56]	Frans Charming:	Thanks Meadhbh
[10:56]	Meadhbh Oh:	cheers! ttfn!
[10:56]	Imaze Rhiano:	thanks Meadhbh
[10:56]	Saijanai Kuhn:	there's bound to be side conversations in Groupies as well
[10:56]	Latha Serevi:	Thanks, Josh, I'm reassured that my question makes sense and the kind of extensibility I seek is a priority. (i.e. ability for a pair of participants to negotiate a different MIME type or something similar, to perform an interaction via some other standard they agree on).
[10:56]	Zha Ewry:	/.me notes well, the notewell http://www.ietf.org/about/note-well.html for people talking on the vWRAP mailing list
[10:56]	Tara Yeats is Offline
[10:57]	Joshua Linden:	Latha: yep, totally.
[10:57]	Imaze Rhiano:	umm... so does this allow me to develope client side assets servers? :P
[10:57]	Zha Ewry:	For those of us talking here, the note is "Saij will post transcripts" (Complete with my typos)
[10:57]	Joshua Linden:	Imaze: I touch on that in my "not in vwrap" preso, actually...
[10:57]	Morgaine Dinova:	I think one thing that didn't quite get handled as Latha may have wished was the very concrete topic of MIME types as data format descriptors. Since data types are going to be an evolving area, clearly there needs to be a way of handling types that one has not seen before.
[10:58]	Saijanai Kuhn:	Imaze once the client gets a way of requesting new services that don't involve asking the login server or region server directly
[10:58]	Imaze Rhiano:	okay.....
[10:58]	Joshua Linden:	Imaze: IMHO, what needs to be standardized is "rez" and "derez"
[10:58]	Zha Ewry:	rez/derez and cues that other services exist
[10:59]	Joshua Linden:	If that's a 3-way dance between "asset source", "region" and "client", then assuming the right trusts are established, "asset source" could be associated with your account (as it is today on SL), associated with the world as a whole (kinda like SL's library, abstractly), or...
[10:59]	Joshua Linden:	some third party, some local filesystem, group properties, etc. anything that would be an "asset source"
[10:59]	Zha Ewry notes this iwhy its a URI ;)
[10:59]	Joshua Linden:	Maybe you're passing around data blobs, maybe just URIs (both URLs and URNs).
[11:00]	Susan Tsuki:	Joshua: just because the asset source, regions, and client are all the same process doesn't mean it's excluded in any way
[11:00]	Morgaine Dinova:	Imaze: since an asset service can be ANYWHERE, that makes client-side asset services possible without VWRAP needing to address the case at all.
[11:00]	Saijanai Kuhn:	to me asset server is a subset of "service" in general, which might include IRC rooms, private whiteboards, and who knows what else
[11:00]	Agent Heliosense is Offline
[11:00]	Susan Tsuki:	and I think the compatibility layer is not very hard
[11:00]	Joshua Linden:	Susan: are you speaking vis-a-vis Cobalt and VWRAP?
[11:01]	Susan Tsuki:	yes
[11:01]	Imaze Rhiano:	yes, Sai
[11:01]	Joshua Linden:	There are a many things that aren't hard. Again, it's simply not a focus
[11:01]	Imaze Rhiano:	master Sai
[11:01]	Joshua Linden:	If you want to work on it, go for it.
[11:01]	Zha Ewry:	And, again, if people work on it, and work on how it fits into the existing work, that's a way to get it into scope
[11:01]	Susan Tsuki:	I want to talk about it without being told it's not a focus. Because I am focusing on it
[11:01]	Saijanai Kuhn:	susan, for Cobalt-SL interop,. you need a layer that can translate SL-specific prim info into smalltalk object messages and translate smalltalk object messages into SL compatible data
[11:02]	Saijanai Kuhn:	doable, but not exactly straightforward
[11:02]	Zha Ewry:	Well, Susan, that means on the VWRAP mailing list, with some discussion on how it fits into the vague frameowkr that's there
[11:02]	Dahlia Trimble:	well people are working on protocols, hopefully there will be a useful intersection :)
[11:02]	Morgaine Dinova:	Susan: join us on the VWRAP mailing list and you can make it a focus, particularly if it gains general interest. There's many shades of interest on the list :-)
[11:02]	Susan Tsuki:	Sai: it's more than that, if you want to host SL clients on Cobalt at the same time that the Cobalt process is logged is as an avi to one or more SL servers
[11:02]	Saijanai Kuhn:	Susan, Croquet hax is the project lead for Cobalt (John Dougan). He generally defers to me when questions about SL-Cobalt interop come up
[11:03]	Joshua Linden:	Oh, that's groovy. I thought you were advocating that the VWRAP WG should spend time on that at higher priority than the chartered work. Don't let me tell you what to do or not!
[11:03]	Zha Ewry:	And, if we see lots of work
[11:03]	Zha Ewry:	and it gets to "hey, we have a consensus to add it in"
[11:03]	Susan Tsuki:	Joshua: I am not a member of the WG
[11:03]	Zha Ewry:	then.. that's very straight forward in the IETF
[11:03]	Joshua Linden:	Anyone who participates on the mailing list is a member of the WG
[11:03]	Zha Ewry:	to be one, just start posting
[11:03]	Joshua Linden:	(no secret handshakes)
[11:03]	Zha Ewry:	+1 Joshua
[11:04]	Susan Tsuki:	before I would assent to that, I want to find out whether the focus is being determined by those with a vested interest in outcomes
[11:04]	Goldie Katsu pouts. She was hoping for a secret handshake.
[11:04]	Saijanai Kuhn:	That's always the case, Susan
[11:04]	Zha Ewry makes the secret gesture behind Joshs back
[11:04]	Joshua Linden:	(there's a double-secret handshake)
[11:04]	Zha Ewry:	The IETF is pretty open
[11:04]	Dahlia Trimble:	oooOO double super secret :D
[11:05]	Zha Ewry:	The charter is a stake in the ground about what people have expressed interest in
[11:05]	Zha Ewry:	The outcome, is specs
[11:05]	Susan Tsuki:	Sai: do you think the VWRAP WG would be actively hostile to Cobalt interoperability developers?
[11:05]	Zha Ewry:	And general consensus
[11:05]	Saijanai Kuhn:	Seeing how I'm interested in that myself and Im the AWG denmother, I don't think its an issue
[11:05]	Dahlia Trimble:	and hopefully they reflect what people want to use
[11:05]	Zha Ewry:	They have to reflect working code, so thsat helps, Dahlia, but yes
[11:06]	Joshua Linden:	Susan: I think the biggest issue you'll run into is that VWRAP is a theory at this point. There are bits like the type system, capabilities, and event queue that are implemented today by SL, OpenSim and LibOMV...
[11:06]	Susan Tsuki:	I hope not, but I wonder how much persuasion people can stand. Eventually people trying to shout others down in their own interest will have an affect
[11:06]	Zha Ewry:	We're prety polite
[11:06]	Latha Serevi:	Susan: if you're not familiaar with IETF processes, as I wasn't, there's a whole strong mindset and lore associated with it, and VWRAP is subject to those constraints.
[11:06]	Joshua Linden:	But beyond that it's theory, not practice, so the most that could be provided is theoretical discussion
[11:06]	Saijanai Kuhn:	Susan, are you pareticipating in the Cobalt developers group? Its on skype. Ask John Dougan/Croquet Hax for an invite
[11:06]	Susan Tsuki:	Thanks, Sai
[11:06]	Saijanai Kuhn:	the developers skype meeting is tomorrow and there's conversations all the time on the skype room
[11:07]	Susan Tsuki:	I am advising a university development team trying to decide between OpenSim and Cobalt
[11:07]	Latha Serevi:	Hey, one more follow-on question on my extensibility topic?
[11:07]	Latha Serevi:	Josh et al, perhaps there's one other part of my question that I didn't see answered: is there a catch-all way to define entirely new interactions to be negotiated between participants? (not the anticipated "parcel properties editor", but a surprise "mind-meld v7 data stream for inter-world coordination"). What might the negotiation look like / what's the catch-all bucket called?
[11:08]	Saijanai Kuhn:	Latha, I think that falls under Zha's proposed client services request protocol
[11:08]	eighthdwarf Checchinato:	be well everyone, I wish you a good day :)
[11:08]	Latha Serevi:	by 8D
[11:08]	Latha Serevi:	*bye 8D
[11:08]	Imaze Rhiano:	Susan - I would choose Opensim - Cobalt is interesting but it's protocol is bit untested and depends highly on platform (IMHO)
[11:08]	Zha Ewry:	I think it falls in that neck of the woods
[11:08]	Joshua Linden:	FWIW, I don't see a reason that either a VWRAP service couldn't expose itself as a Cobalt peer, or that a Cobalt peer couldn't expose VWRAP region services. That sort of "protocol gateway" approach was talked about a bit on MMOX. The Forterra dude (John Watte?) was a big advocate of that approach, if I'm recalling correctly
[11:09]	Dahlia Trimble:	I need to poof off to another meeting myself... bye all :D
[11:09]	Zha Ewry:	There are som funny constraints which get you into HAL/DIS land, but I agree Josh
[11:09]	Saijanai Kuhn:	Joshua, sure, but you'd need a smalltalk thingie (VM/interpreter/translator) in the mix at some point
[11:09]	Joshua Linden:	Latha: I believe that falls into the space Zha's been thinking about - how a client even becomes aware that one of these services exists.
[11:09]	Susan Tsuki:	Joshua: agreed; how about a Cobalt peer acting as a VRAP client and server simultaniously?
[11:09]	Zha Ewry:	I don't see why not, up to a point, Susan
[11:09]	Joshua Linden:	Susan: you could slice it that way.
[11:10]	Zha Ewry:	The tricky bits are where you bend the "Here is the long term stabel URI for this bit of land"
[11:10]	Susan Tsuki:	nothing is forever
[11:10]	Latha Serevi:	Thanks, I'll keep an eye out for "client services request" part of the protocol.
[11:10]	Zha Ewry laughs
[11:10]	Zha Ewry:	Well, no, but cnn.com is pretty stable
[11:10]	Zha Ewry:	more so, thsan the typical cobalt/croquet region
[11:10]	Zha Ewry:	There are some spots like that
[11:10]	Zha Ewry:	which would need some love
[11:11]	Zha Ewry:	None of it beyond reasonable discussion
[11:11]	Susan Tsuki:	Imaze: they are developers looking to improve things, not users in the general sense
[11:11]	Saijanai Kuhn:	right now, they're workign on a renderingless persistent client that could be hosted on a normal server. Biasically it simply doesn't draw anything directly (it eats the rendering commands
[11:12]	Joshua Linden is gonna run, toodles all!
[11:12]	Saijanai Kuhn:	but y ou gotta understand that every Cobalt client is expected to "process" every cobalt message. The headless server still generates the drawing commands and forwards them to the distribution server, which actually sends them back tot he non-rendering server which then ignores them
[11:12]	Morgaine Dinova:	Toodles, Josh :-)
[11:13]	Imaze Rhiano:	from academic standpoint - Cobalt might be more untraditional and offer more interesting cases for scintific studies
[11:13]	Zha Ewry:	Thanks Josh
[11:13]	Susan Tsuki:	Sai: I wonder if a boolean headless in the distribution list would help
[11:14]	Zha Ewry:	SO.. We're past our usual 11:00cut of, but people are welcome to keep talking
[11:14]	Saijanai Kuhn:	Don't thin so. The way TeaTime works, the originating client (server) doesn't process the messages until they come back from the distributor (forget its name)
[11:15]	Aurora Kitaj is Offline
[11:15]	Susan Tsuki:	Sai, thanks very much for the contact names. Zha, thank you too, and Imaze, and everyone with good advice
[11:15]	Zha Ewry keeps wanting the tea time distributor to be Troley
[11:15]	Latha Serevi:	Sai, shall I post the transcript? and was there a slides URL yet?
[11:15]	Zha Ewry:	Trolly
[11:15]	Zha Ewry:	sheesh
[11:15]	Morgaine Dinova:	I actually find our preoccupation with world similarity or differences as rather funny. One thing I can guarantee even without a crystal ball: the worlds ahead will be nothing like what we imagine currently. And they'll either use extensions of current protocols like VWRAP, or these protocol will become 100% obsolete.
[11:15]	Saijanai Kuhn:	you'd have to make sure that rendering and non-rendering info was perfectly separate before you could decide to NOT send a rendering message
[11:16]	Susan Tsuki:	Morgaine, maybe someone will fork VWRAP to use Google Checkout instead of L$s
[11:16]	Morgaine Dinova:	Sai: "space cadet"? <grin> Not aware of that metaphor :-)
[11:16]	Saijanai Kuhn:	I pretty much define it
[11:17]	Morgaine Dinova:	Susan: odder things have happened :-)
[11:17]	Morgaine Dinova:	Not that VWRAP deals with L$ of course
[11:18]	Susan Tsuki:	I'm pretty glad they support JSON in http://tools.ietf.org/html/draft-hamrick-llsd-00 -- I knew I was in for in when I got told that was off topic....
[11:18]	Zha Ewry:	the most vwrap is likely to do, is allow a "Money here" slot in some messages, and allow people to stuff in what they define
[11:18]	Goldie Katsu:	or QQ currency?
[11:18]	Zha Ewry:	Slot in what you will
[11:18]	Zha Ewry:	vwrap ends where we say
[11:18]	Zha Ewry:	"You can include payment info here"
[11:19]	Morgaine Dinova:	Coloured beads. VWRAP must support coloured bead currency. ;-)
[11:19]	Goldie Katsu:	(Tencent QQ, not QQ as complaint)
[11:19]	Zha Ewry:	Wampum!
[11:19]	Saijanai Kuhn:	http://www.opencroquet.org/index.php/System_Overview
[11:19]	Saijanai Kuhn:	I believe the term I'm looking for is Croquet Router