User:Zero Linden/Office Hours/2008 June 05

From Second Life Wiki
< User:Zero Linden/Office Hours
Revision as of 11:21, 5 June 2008 by Harleen Gretzky (talk | contribs) (New page: * [8:35] <font color="Black">Zero Linden: hello all</font> * [8:35] <font color="Gray">Harleen Gretzky: Hi Zero</font> * [8:35] <font color=...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
  • [8:35] Zero Linden: hello all
  • [8:35] Harleen Gretzky: Hi Zero
  • [8:35] Sheet Spotter: Good morning!
  • [8:36] Rex Cronon: hello everybody
  • [8:36] Saijanai Kuhn: non-stop errors with groupies IM
  • [8:37] Sheet Spotter: chuckles at the pile up over Harleen.
  • [8:37] Zero Linden: well - I'm only running on one cup of coffee..... so no promises
  • [8:38] Elric Ember: lol
  • [8:38] paulie Femto:  :)
  • [8:38] Zha Ewry: winces at a lightly caffeinated Zero
  • [8:38] Saijanai Kuhn: scary
  • [8:38] Sheet Spotter: slips a few chocolate covered espresso beans onto Zero's desk.
  • [8:39] Zero Linden: Well - Welcome to my office hours
  • [8:39] Saijanai Kuhn: spam accomplished
  • [8:39] Zero Linden: Now clearly running on summer time!
  • [8:39] paulie Femto: thanks!
  • [8:39] Zero Linden: As a reminder - transcripts are posted to the public wiki - speak freely - speak in public
  • [8:39] Zero Linden: We are here, as always, to talk about the architecture of SL - present and future (and past if you buy me a beer...)
  • [8:40] Vide Szondi: I'm just here 'cuz of the "spam" (tnx) and my beach is being rolling restarted....
  • [8:40] Courtesan DeCuir: good morning Zero
  • [8:40] Zero Linden: Well, we're happy to have you here, Vide
  • [8:40] Irah Anatine: Hello all:)
  • [8:40] Saijanai Kuhn: o! Good Morning Teacher
  • [8:40] Saijanai Kuhn: is a creature of habit
  • [8:40] Rex Cronon: hiii
  • [8:40] Aria Eichel: Hello
  • [8:40] Zero Linden: Agenda items? We had one from Tuesday: 1) OGP and object formats
  • [8:41] Saijanai Kuhn: Last i heard, Enus still hadn't gotten licensing approval for the test harness.
  • [8:42] Vide Szondi: Well, if you'd be entertained by a stupid question - what's the state of an iPhone client (he asked trying to be topical and current)?
  • [8:42] Zero Linden: 2) Phone clients
  • [8:42] Saijanai Kuhn: several organizations have announced their own, if you check google
  • [8:42] Zero Linden: true
  • [8:42] Zero Linden: that is about all there is to say
  • [8:42] Zero Linden: wait ... i have a link....
  • [8:42] Zha Ewry: 3) Region Handles and location conflation
  • [8:42] Zero Linden: rummages through e-mail
  • [8:43] Vide Szondi: ok, tnx...just thought there might be news given the master's voice happening Monday
  • [8:43] Zero Linden: [1]
  • [8:43] Saijanai Kuhn: and if we ever get the test harness working, a script-based lightweight client is kinda built into the whole thing
  • [8:43] Zero Linden: LL isn't working on an iPhone client
  • [8:43] Zero Linden: though I would use one if there was one
  • [8:43] Vide Szondi: Kewl - thanks!
  • [8:44] j3rry Paine: doesn't have a phone
  • [8:44] Zero Linden: but - I doubt the graphics support in the iPhone is good enough for a full 3D experience rendered directly
  • [8:44] Vicero Lambert: hope it works on windows mobile :-p
  • [8:44] Vide Szondi: (I'm contemplating my first iPhone after years as a Danger addict)
  • [8:44] Zero Linden: but, doing some form of render-on-server-send-compressed-video might work
  • [8:44] Zero Linden: or perhaps some form of limited access client (IM and voice only?)
  • [8:44] Saijanai Kuhn: was thinking that a mini-map with your location marked would be about as good as it gets for a realtime interface
  • [8:45] Stephen Posaner: wants one of these [2]
  • [8:45] Vide Szondi: indeed - that's the kind of thing I hoped for...please - don't let me kidnap the meeting!!
  • [8:46] Saijanai Kuhn: ZSro that's been demonstrated for the iPhone about a 1FPS it looked like
  • [8:46] Dahlia Trimble: has a fujitsu lifebook u10 but the frame rate is kinda low
  • [8:46] j3rry Paine: most sl'ers can't type with their thumbs and anyway, at least one hand is needed for ... other things
  • [8:46] Stephen Posaner: if you text on a smart phone you can do any thing
  • [8:46] Zero Linden: I've met the oqo folks - really smart people and very pleasant to hang out with - not your typical silicon valley geek
  • [8:47] Zero Linden: (mind you, I am more the typical silicon valley geek, myself....)
  • [8:47] Zero Linden: Okay - '
  • [8:47] Zero Linden: well
  • [8:47] Saijanai Kuhn: says the guy who majored in computer music
  • [8:47] Zero Linden: Let's go
  • [8:47] Zero Linden: topic 1 was OGP and object formats
  • [8:47] Zero Linden: SO
  • [8:47] Zero Linden: The first thing that comes to my mind (and what I said on Tuesday)
  • [8:48] Zero Linden: is that OGP should just use some content-negotiation like sequence to agree on
  • [8:48] Zero Linden: MIME-type between any two
  • [8:48] Zero Linden: parts of the dialog (viewer and region, viewer and agent domain, agent domain and region)
  • [8:48] Saijanai Kuhn: OGP ==> https://wiki.secondlife.com/wiki/SLGOGP_Draft_1
  • [8:49] Zero Linden: The only question comes- at what scale do you do this negotiation
  • [8:49] Zero Linden: at start up?
  • [8:49] Zero Linden: for each object transferred?
  • [8:49] Saijanai Kuhn: I'd say, at the point where AD starts talking to current grid about rezzing avatar
  • [8:49] Zero Linden: If they are assets - as we expect assets to be transferred as standard HTTP resources
  • [8:49] Zero Linden: there is already content negotiation built in
  • [8:50] Zero Linden: "current grid" ?
  • [8:50] Saijanai Kuhn: region domain
  • [8:50] Zero Linden: So - you're saying - when a viewer connects to a region, the viewer and the region content negotiate acceptable object formats?
  • [8:50] Zero Linden: seems reasonable
  • [8:52] Saijanai Kuhn: part of the optimal aspect of getting onto the grid. AD asks: anything special? And the grid replies: I handle this object forma, this extra IM format, etc...
  • [8:52] Zha Ewry: With some oddities about adjacent regions
  • [8:52] Zha Ewry: Its going to be really hard, if the set of child agents and content is coherent
  • [8:53] Zero Linden: s/if/unless/ ??
  • [8:54] Zero Linden: So, in some cases
  • [8:54] Zero Linden: format can be handled by cap request
  • [8:54] Zero Linden: for example
  • [8:55] Zero Linden: I'd imagine that we'd define an initial IM set of resources
  • [8:55] Zero Linden: If later we had "augmented-IM" with more features that couldn't be done via direct extension of the current protocol
  • [8:55] Zero Linden: that we'd do it by saying - well, ask for resource IM2 from the seed cap
  • [8:55] Zero Linden: and if you don't get that, then fall back to IM
  • [8:56] Zero Linden: I think the only times we'd prefer a content type negotiation separate from the resource cap request
  • [8:56] Zero Linden: is when the protocol is sufficiently involved... and where the protocol doesn't really change at all due to the content following over it
  • [8:56] Zero Linden: So, for example
  • [8:57] Zero Linden: Object data -- initial parameters and update messages -- squarely fall into this camp
  • [8:57] Zero Linden: Texture data too --
  • [8:57] Zero Linden: Animations and Sound
  • [8:57] Zero Linden: but - I'm not sure what else
  • [9:00] Zero Linden: okay - we seem in silent understanding
  • [9:00] Zero Linden:  :-)
  • [9:00] Zero Linden: so - moving on
  • [9:00] Zero Linden: 2) was phone clients and I think we handled that
  • [9:00] Zero Linden: so
  • [9:00] Zero Linden: 3) Region Handles and location conflation
  • [9:01] Zero Linden: Zha?
  • [9:01] Morgaine Dinova: Good word, "conflation". Can mean anything you want ;-)
  • [9:02] Sheet Spotter: thinks it means Zha needs more coffee too.
  • [9:02] Sheet Spotter: [3]
  • [9:02] Zha Ewry: Ahh
  • [9:02] Zha Ewry: No
  • [9:02] Zha Ewry: It means I'm deep in code
  • [9:02] Tao Takashi: Hi
  • [9:02] Zha Ewry: so...
  • [9:02] Zha Ewry: When we do a place_avatar
  • [9:03] Zha Ewry: the region hands the client back a location_x, locatoin_y
  • [9:03] Zha Ewry: the region hands the client back a location_x, locatoin_y
  • [9:03] Zha Ewry: And.. from this the client builds a region handle
  • [9:03] Zha Ewry: thus locking together the handle creation scheme and the current x/y map
  • [9:04] Zha Ewry: conflating, what it, in many ways, a private issue between the sims in a grid (handles) and the map (which might also be a private issue in a grid)
  • [9:04] Zero Linden: Hmmm.... that is a good catch
  • [9:04] Zha Ewry: chuckles
  • [9:04] Zha Ewry: turns out opensim builds handles differently
  • [9:04] Zha Ewry: Sort of hits you in the face with a 2x4 when you get into the code
  • [9:04] Zero Linden: I actually quested the region info being in the place_avatar message and have suggested that we have a region_info cap that returns such stuff on demand
  • [9:04] Zero Linden: demand
  • [9:04] Zero Linden: SO
  • [9:05] Zha Ewry: Well, we could just as easily
  • [9:05] Zero Linden: In one view of a grand glorious world - there is ONE MAP TO RULE THEM ALL
  • [9:05] Zha Ewry: pass the region handle back
  • [9:05] Zha Ewry: Even if there is one map
  • [9:05] Zero Linden: which means that all region domains would need to be registered somewhere
  • [9:05] Zha Ewry: you still don't want the handle to be calculated
  • [9:05] Zha Ewry: That REALLY constrains the use of it as an opaque token
  • [9:05] Zero Linden: and then --- I suppose it would be up to the agent domain to enforce that the region coord's returned by the region were within its
  • [9:05] Zero Linden: registered region domain's area
  • [9:06] Zero Linden: Ah - you mean within the client itself? gotcha
  • [9:06] Zero Linden: so - the client kinda wants to know if it has a connection, handle, whatever to a particular region already
  • [9:06] Zero Linden: if it relied on each region to announce to it the Cartesian neighbors
  • [9:07] Zero Linden: then - well, what if they didn't agree?
  • [9:07] Zero Linden: the viewer might end up with two handles to two to regions that occupy the same area
  • [9:07] Zha Ewry: Well.. I think.. and we can bat this about a bit
  • [9:07] Zha Ewry: The question is pretty much how we think of the handle
  • [9:08] Morgaine Dinova: Zero: that almost philosophy, but a good point. In a virtual universe, do locations all have absolute locators, or are they inherently granular, with inner (hidden) locators that require querying a node in the tree for local access?
  • [9:08] Zha Ewry: Is it opaque, or does it convey specific meaning?
  • [9:08] Morgaine Dinova: In RL, everything has an absolute locator
  • [9:08] Zha Ewry: If it has implicit structure (and the message of URIs and the web, is NO!) then you have to document it, and live with it. Which is generally bad
  • [9:10] Sheet Spotter: I assumed a region had a URI to describe its location, and an agent had a URI to describe its relative position within the region.
  • [9:10] Morgaine Dinova: The concept of documentation is broken. Everything has to self-document, or the documentation scale.
  • [9:10] Morgaine Dinova: doesn't scale*
  • [9:11] Zha Ewry: There are these lovely handles
  • [9:11] Zha Ewry: 64 bits
  • [9:11] Saijanai Kuhn: but we're talking about CAPs here, no?
  • [9:11] Tao Takashi: what's in this handle anyway? and what is it used for?
  • [9:11] Tao Takashi: I am not so much in the code right now ;-)
  • [9:11] Zero Linden: the handle is a reference to the information the viewer has about a region
  • [9:12] Zero Linden: So -
  • [9:12] Zero Linden: for example
  • [9:12] Morgaine Dinova: Sheet: if that URI refers to the region, then the URI is not an absolute locator, it's a relative one
  • [9:12] Zero Linden: the viewer stores internally, after TP to a region at 100,100
  • [9:12] Zero Linden: Handle(100,100) --> region URL, region IP/Port, queues, terrain ......
  • [9:12] Tao Takashi: ok, but that's more an implementation issue then?
  • [9:13] Zero Linden: then when it sees into the region to the north
  • [9:13] Zero Linden: it constructs handle(100,101)
  • [9:13] Zero Linden: Now
  • [9:13] Zero Linden: when you TP (or cross) into that region
  • [9:13] Zero Linden: the viewer says
  • [9:13] Tao Takashi: so 100,100 is the position of a region on the map then
  • [9:13] Zero Linden: "hey - I can see into the region to the south)
  • [9:13] Zero Linden: (yes, Tao)
  • [9:13] Morgaine Dinova: Personally, I don't think that absolute locators have a future in virtual worlds. So, all locators must contain a region reference, using the widest possible meaning of "region"
  • [9:13] Zha Ewry: And, this bakes in some pretty deep map assumptions
  • [9:13] Zero Linden: And that is at 100,100
  • [9:14] Zero Linden: let's see if Have info about Handle(100,100)
  • [9:14] Zero Linden: Oh - look - there it is
  • [9:14] Zero Linden: In other words, it doesn't ask the current region for what is the region to the south - because it bakes the map assumption into it
  • [9:15] Tao Takashi: does it need to know the x,y-coords? can't it just ask for some URLs of regions to some direction?
  • [9:15] Morgaine Dinova: Zero: baking is bad, unless bakes have a TTL
  • [9:15] Sheet Spotter: I assumed the client would ask the region for the adjacency information.
  • [9:15] Zero Linden: yeah - it could - and it could test for URL equivalence
  • [9:15] Zero Linden: though that can be a non-trivial problem
  • [9:15] Zero Linden: Another idea is that each region has a region ID (a UUID)
  • [9:16] Tao Takashi: I just wanted to say that ;-)
  • [9:16] Tao Takashi: why not ask some URL for some UUID
  • [9:16] Tao Takashi: and compare this
  • [9:16] Zero Linden: and the viewer could ask the current region for the URLs of the neighbors, then ask those URLs for the region IDs
  • [9:16] Tao Takashi: what does it need the ids for?
  • [9:16] Tao Takashi: why does it need to compare it?
  • [9:16] Tao Takashi: (with what?)
  • [9:16] Zero Linden: and if they matched existing region data in the viewer, the viewer could say ("oh, cool, I'm already connected there and have the water height, parcel map, etc...)
  • [9:16] Morgaine Dinova: Zero: yes, the name of a region should be just a friendly tag, but the UUID should be the real thing
  • [9:17] Zero Linden: Tao - because when you walk over a sim boundary, you don't want to have to refetch the region data for the region you just left
  • [9:17] Zero Linden: you sort of want to say "I know that the region I was just connected to is the region to the south of the region I just walked north to enter"
  • [9:17] Zha Ewry: Yeah, you clearly want to keep as much context as possible
  • [9:18] Zero Linden: Well, yes, I don't think we should consider names to be the "true id"
  • [9:18] Zha Ewry: you just really would prefer not to keep it based on the current x/y fixed map
  • [9:18] Zero Linden: but perhaps the URL is sufficient
  • [9:18] Tao Takashi: and you cannot simply remember that URL?
  • [9:18] Morgaine Dinova: In the wider metaverse, regions can create their own UUID names ... and only very rarely will a clash dispute be need to be resolved.
  • [9:18] Tao Takashi: or do you want to make sure that it really is the same?
  • [9:18] Zero Linden: well - there is the question of do we need to do URL canonicalization before comparing
  • [9:18] Tao Takashi: like you enter a new region, ask for the neighbors, get back the URLs and UUIDs and compare if the one you left is really the one this region thinks is the neighbor?
  • [9:18] Zero Linden: but it is probably reasonable to expect that within a region domain, it will use consistent URL forms for any given region
  • [9:19] Zero Linden: Tao - yes
  • [9:19] Tao Takashi: we can demand from a region domain to serve the same URL when it's the same region
  • [9:19] Zero Linden: but do you get the regionID, the regionURL, or both from the current region (as an answer to "who are my neighbors?")
  • [9:19] Tao Takashi: we can also demand to provide some UUID, I guess that does not cost too much
  • [9:19] Tao Takashi: well, if there's an id, why not simply returning both directly
  • [9:20] Tao Takashi: it's not a web service used that often anyway (I guess)
  • [9:21] Zero Linden: right - just worrying about "out-of-sync'ness"
  • [9:21] Sheet Spotter: Which is a more scalable identifier for a region: UUID or URL?
  • [9:21] Morgaine Dinova: Sheet: UUID
  • [9:22] Zero Linden: Now - I think it is reasonable for use to expect that if I walk north from sim A into sim B
  • [9:22] Zero Linden: that sim B MUST report sim A as the south neighbor
  • [9:22] Zero Linden: if it is doesn't - I'm fine with the viewer FREAKIN OUT
  • [9:22] Sheet Spotter: "You have entered a maze of twisty passages"
  • [9:22] Morgaine Dinova: Zero: unless it's changed during the transfer.
  • [9:22] Zero Linden: If this is the case, and we consider global region coordinates to be really only global to the region domain
  • [9:23] Zero Linden: then the region coordinates, coupled with the region domain, become a possible reasonable handle within the viewer
  • [9:23] Zha Ewry: I think the viewer can freak out if the land doesn't follow it's expected rules
  • [9:23] Zero Linden: Good point, Morgaine...
  • [9:23] Morgaine Dinova: Zero: region adjacency may be quite static in LL grids, but it WONT be in the wider gridverse. The client should not freak out when the universe changes
  • [9:23] Zha Ewry: I'm not, sure, long term, this is always simple gridded cartesian,but I agree
  • [9:23] Zero Linden: In fact there is existing protocol to handle changes in neighbors while you're in world
  • [9:24] Zero Linden: (always amazed that it works, too....)
  • [9:24] Tao Takashi: we also should add a z-coordinate though ;-)
  • [9:24] Zero Linden: SO perhaps your current location DOES define your view of reality
  • [9:24] Morgaine Dinova: I was amazed that SL worked in year 1. Not amazed that it works *less well* in year 4.
  • [9:25] Zero Linden: Is anyone here planning on building a viewer that could handle regions that were above or below other regions?
  • [9:26] Saijanai Kuhn: You'd need to talk to relXtend or Openviewer about that
  • [9:26] Cane Janick: assumes the answer is no
  • [9:26] Tao Takashi: well, I would like to have space :)
  • [9:26] Zero Linden: for example- I'd be hard pressed right now to get my camera in a position that would view regions above or below
  • [9:26] Tao Takashi: and underground
  • [9:26] Morgaine Dinova: Zero: I'm planning (in my mind at least) to build a viewer with no prior assumptions about topology.
  • [9:27] Tao Takashi: and as I am not sure what people will experiment with I wonder if adding a z-coord will hurt
  • [9:27] Zero Linden: Morgaine - I'd love to find out how you construct the management of space for both rendering and motion
  • [9:27] Zero Linden: *motion
  • [9:27] Zha Ewry: I think, we can assume, in the next 2-3 years, that the plain flat 2d grid assumption is going to break, but I agree it's non trivial
  • [9:27] Morgaine Dinova: Zero: fortunately Newton (and Einstein) can be ignored in VWs :-)
  • [9:28] Tao Takashi: but maybe not understood by people if you make it too fancy ;-)
  • [9:28] Tao Takashi: but up/down should be understood at least
  • [9:28] Zero Linden: point taken
  • [9:28] Zero Linden: but we must also accept that I can't think of a viewer for any 3D system that handles such a thing
  • [9:29] Morgaine Dinova: We still have to deliver "WHAT THE PEOPLE WANT" though ... even though we're not limited by that, in theory.
  • [9:29] Zero Linden: I have a 9:30 meeting all, so I'm going to have to wrap
  • [9:29] Zero Linden: thanks all for coming
  • [9:29] Morgaine Dinova: Ty Zero
  • [9:29] Elric Ember: ty
  • [9:29] Rex Cronon: bye zero
  • [9:30] Cane Janick: ty
  • [9:30] Sheet Spotter: Thank you for this hour, Zero.
  • [9:30] Courtesan DeCuir: thank you Zero
  • [9:30] Morgaine Dinova: Philip needs an OH
  • [9:30] Zha Ewry: This was good, Zero, and I think we need to look for similar assumptions lurking in the protocol
  • [9:30] Morgaine Dinova: Zha: what are you hacking currently?
  • [9:31] Saijanai Kuhn: thanks zero