User:Zero Linden/Office Hours/2008 May 01

From Second Life Wiki

Second Life Wiki > Zero Linden/Office Hours/2008 May 01
Jump to: navigation, search
  • [8:32] Morgaine Dinova: some group needs to look into more advanced object volume semantics. Would be nice if clothes could really drape across bodies.
  • [8:32] Zha Ewry: Morning Zero. No fire alarm today?
  • [8:32] Zero Linden: not yet...
  • [8:33] Morgaine Dinova: Hiya Zero :-)
  • [8:33] Infinity Linden: hola Zero
  • [8:33] Zero Linden: but the coffee is still brewing....
  • [8:33] Zha Ewry: Oh. My.
  • [8:33] Zha Ewry: Defacinated Zero
  • [8:33] Zha Ewry: worries
  • [8:33] Morgaine Dinova: You always get advance notice of Zero's arrival, because he always enters mug-first ;-)
  • [8:33] Basil Wijaya: you said the word. I need an RL coffee, come back in 5
  • [8:33] Lillie Yifu: hair, there will be undying gratitude when hair drapes.
  • [8:34] Morgaine Dinova: Lillie: yes!!!! Hair must drape, not slice off our necks!
  • [8:34] Zha Ewry: Having all the flexies properly not intersect the ave would be nice
  • [8:34] Infinity Linden: scribbles notes
  • [8:34] Morgaine Dinova: Hehe
  • [8:35] Morgaine Dinova: ey, maybe we can make that today's agenda ---- far off targets.
  • [8:35] Saijanai Kuhn: just scribbles
  • [8:35] Morgaine Dinova: #1 Hair and clothes draping
  • [8:35] Zha Ewry: Wrong lindens, tho, that's 99% client side
  • [8:35] Zero Linden: Right
  • [8:36] Morgaine Dinova: Seriously, I'm just thinking whether that has server-side implications, eg. on bounding boxes
  • [8:36] Zero Linden: Oh, I dunno.... ADHP --- Avatar Draped Hair Protocol....
  • [8:36] Morgaine Dinova: Hahaha
  • [8:36] Lillie Yifu: flexi is client side... would it be possible to change the flexi algorythm on the client so that it does't make them bumpinto objects?
  • [8:36] Infinity Linden: hair or clothes could seriously pound the server-side...
  • [8:37] Zha Ewry: Well, the client knows how to render, but not so much about the scenescape's bounding box
  • [8:37] lonetorus Habilis: and considering the 100-200ms latency across the atlantic, then sl would look and feel wierd to the europeans
  • [8:37] lonetorus Habilis: on that note, any idea if there will be hosting centers in europe?
  • [8:37] Zha Ewry: and you *DON't* really want to do too much flexi like stuff on the sim
  • [8:37] Zero Linden: as an adendum to one of our prior sessions, I recently published this amusing wiki page
  • [8:37] Zero Linden: https://wiki.secondlife.com/wiki/Unicode_In_5_Minutes
  • [8:38] Zero Linden: For anyone who needs a quick intro to Unicode
  • [8:38] Morgaine Dinova: Could avs have 2 different bounding boxes, one for the server side to regulate av-av interactions and with macro objects, and a fine-mesh client-side bounding box to control clothes and hair draping?
  • [8:38] Zero Linden: I think, even if you wanted one Av'
  • [8:38] Zero Linden: Av's hair to drape around another Av's form (say, when cuddling)
  • [8:39] Zero Linden: I think that would still all be client side
  • [8:39] Antonio Asano: hi all
  • [8:39] Pyro Watler: hi all
  • [8:39] Zha Ewry: The only question, I think, is whether the client has the attachments have proper bounding boxes client side
  • [8:39] Morgaine Dinova: Yep, seems like we can tackle 99% of the problem client-side.
  • [8:39] Zero Linden: It's only if we need object's to have sensors like llIsHairDrapedUponMe() that we'd need to go to the server
  • [8:39] Infinity Linden: Yea! the page has another reference to the Glagolitic Spidery Ha
  • [8:39] Zha Ewry: "flexiprim touch"
  • [8:40] Zha Ewry: You can't tell if its hair, or a scarf
  • [8:40] Zero Linden: Zha - indeed, the client does - in fact it is the server that has an approximation of the AV
  • [8:40] Zha Ewry: Or a burha drapped on the ave
  • [8:40] Morgaine Dinova: Zero: what's the server-side bounding box for an av like anyway?
  • [8:40] Morgaine Dinova: Just a capsule?
  • [8:42] Zero Linden: A cylinder, if I recall
  • [8:42] Zero Linden: So - Agenda Items?
  • [8:44] Morgaine Dinova: Don't have one myself today, unless you want to discuss distant futures ;-)
  • [8:44] Wize Sigal: Sorry for that dropped plant pot
  • [8:44] Lillie Yifu: There is another one, could there be an algorythm to edit anmations os that we don't have parts of the avatar itself going through the avatar?
  • [8:44] Lillie Yifu: It would get rid of the kung fu auto-mastectomy problem
  • [8:45] Zero Linden: Lillie - animation formats are an excellent area for this group to do some research
  • [8:45] Saijanai Kuhn: amazons simply didn't keep them. INTerfered with archery
  • [8:45] Morgaine Dinova: Zero: one not-so-distant future that's worth discussing is world topologies. SL seems to have 2D tiled grid hardwaired in ... or does it? #
  • [8:45] Infinity Linden: Morgaine... are you thinking of a hex grid?
  • [8:46] Leffard Lassard: Perhaps, problems with denying single caps during a cumulative caps request.
  • [8:46] Zero Linden: okay - Agenda so far is looking like: Animation formats / Grid Topology / and I'll add update on reverse-HTTP
  • [8:46] Morgaine Dinova: No, I was thinking of 3D topologies
  • [8:46] Infinity Linden: ah ah...
  • [8:46] Dyne Talamasca: A 3d grid would increase the border sims, of course.
  • [8:46] Infinity Linden: scribbles more notes
  • [8:46] Morgaine Dinova: Planets especially, and space habitats
  • [8:46] Zero Linden: okay, insert denying caps after topology
  • [8:46] Infinity Linden: lol
  • [8:46] Rex Cronon: hi everybody. sorry for being late
  • [8:47] Morgaine Dinova: Hi Rex
  • [8:47] Zero Linden: Rex - anything for the agenda
  • [8:47] Rex Cronon: hi
  • [8:47] Saijanai Kuhn: documentation standards on the wiki...
  • [8:48] Rex Cronon: textures/sculpties download priority?
  • [8:48] Rex Cronon: maybe
  • [8:48] Lillie Yifu: Oh yes... I've had several people ask what would it take to divorce prim allocations from space, so that parcels could have arbitrary #D shapes and arbitrary parcel allocations.
  • [8:48] Morgaine Dinova: The very fact that the agenda item is called "Grid Topology" highlights the problem. :-) It's "Grid" everywhere, even in the protocol name! Eww ...
  • [8:49] Dyne Talamasca: Volume topology lacks a bit of zing.
  • [8:49] Infinity Linden: s/Grid/3Space/ ?
  • [8:49] Zero Linden: Okay - let's got on with it
  • [8:49] Zero Linden: 1st: Animation format
  • [8:49] Zero Linden: So, as you know, animations in SL use an industry standard format BVH
  • [8:50] Morgaine Dinova: 3Space isn't a bad term :-) I've not heard that one suggested before. Or VSpace?
  • [8:50] Zero Linden: as I understand it, BVH doesn't anticipate variability in the size of the skeletal features of the character it applies to
  • [8:50] Morgaine Dinova: From Poser-1
  • [8:50] Saijanai Kuhn: BVH is limited though. Assumes completely human characteristics
  • [8:50] Zero Linden: I believe we do some voodoo - we assume the animation was against an avatar of some base size
  • [8:50] Rex Cronon: in poser u have animal skeletons too
  • [8:50] Zero Linden: and then scale it to match a given AVs skeleton
  • [8:51] Nika Talaj: We also seem to lose detail on upload.
  • [8:51] Zero Linden: well, BVH is a pretty restricted format, I believe storting Quaternions in short values.....
  • [8:51] Morgaine Dinova: Isn't there an open, path-based animation format by now? Things must have progressed since the early days of Poser.
  • [8:51] Saijanai Kuhn: it was designed for motion capture from humans and nothing else, I believe
  • [8:51] lonetorus Habilis: whats the file size limit on uploaded bvh files?
  • [8:52] Zero Linden: I don't know
  • [8:52] Zero Linden: The issue is that, given we want to create animations to a wide variety of skeleton sizes (especially with differing ratios between parts)
  • [8:52] Morgaine Dinova: It must be a low limit, I've not seen any long complex dances
  • [8:52] Zha Ewry: That's related to the scaling, and the fact that the bones, don't change when the Aves chaznge ratios
  • [8:53] Zero Linden: it is very hard to use an analytic format to describe the animation of, say, holding your elbow with the opposite hand
  • [8:53] Zha Ewry: So, long legged aves, and short legged aves, don't move the same, but the skeleton code assumes they do
  • [8:53] Saijanai Kuhn: and always the same joints...
  • [8:53] Rex Cronon: i think u can have a max of 30 frames
  • [8:53] Zero Linden: or touching your nose
  • [8:53] Zero Linden: Zha, I believe we scale the parts of the post to the skeletal parts... but the problem here is that
  • [8:54] Zero Linden: scaling the arm quaternions, for example, isn't going to make the hand touch all manner of possible nose locations
  • [8:54] Morgaine Dinova: Zero: those things would probably need animation to be tied to physics, and using constraints instead of pathing. A good way to go for the future, but pretty hard.
  • [8:54] Zero Linden: and the scaling code, from the format, has no way of knowing if those angles in the elbow are there to make your fingers align with your nose, or your ear, or just up in the air
  • [8:54] Zha Ewry: Well, the nose, isn't accounted for at all, in the bones, right? And there isn't a way to put the hand, relative to it
  • [8:55] Zero Linden: Morgain - right we need a way of saying "In this frame, the hand touches the nose"
  • [8:55] Zha Ewry: (You could otherwise say, put my and 0.1m from the center of my node attach point)
  • [8:55] Zero Linden: and leave the angle kinematics to do the rest
  • [8:55] Rex Cronon: sorry
  • [8:55] Zero Linden: now it turns out - we have the technology in house to do those inverse kinematics
  • [8:55] Saijanai Kuhn: Bivision doesn't exist any more. Its ironic that an industry standard format was created by a company that went out of business and no-one is using something better
  • [8:55] Zero Linden: what we don't have is the format and the openly available tool chain for people to author in it
  • [8:56] Zero Linden: SOOOOOO
  • [8:56] lonetorus Habilis: well, to ave more natural animations in sl, then in a distant future we could hope for something like Euphoria [(http://en.wikipedia.org/wiki/Euphoria_%28software%29)]
  • [8:56] Burhop Piccard: Tool chain?
  • [8:57] Zero Linden: the short answer is - go out and join (or pester your developer friends to join) open animation authoring software projects and
  • [8:57] Zero Linden: get them to implement tools to do this and promote a format for it
  • [8:57] Morgaine Dinova: Well I don't think we're going to invent a whole toolchain. So, we need to see if any good open formats are available ... just better than BVH.
  • [8:57] Lillie Yifu: Now there is something that LL should put out, and it would help keep SL a standard, even if other platforms come out.. because an IK animation format would be adopted all over quickly
  • [8:57] Zero Linden: We'd love it - only we dont' have priority right now to do it ourselves
  • [8:57] Zero Linden: (besides, I'm pretty sure there are others that can build those sorts of tools better than LL could!)
  • [8:58] Zero Linden: I'll see if I can schedule a whole office hours on future of animations and get someone like Aura Linden to come talk
  • [8:58] Taff Nouvelle: talking about nose position for example, would that mean more possible attach points?
  • [8:58] Nika Talaj: Could LL do something about the compression on upload?
  • [8:59] Morgaine Dinova: Zero: could the entire issue be factored out from base SL, perhaps? Allow any number of av representation and animation formats ("plug in" of course, need to be buzzword compliant) and SL simply provides the default?
  • [8:59] Lillie Yifu: With a format, then animation programs could export to it. Poser and Maya both do IK now.
  • [8:59] Yuu Nakamichi: does blender do IK?
  • [8:59] Zero Linden: Morgaine - absolutely - we should be providing a MIME type with that data
  • [8:59] Dyne Talamasca: I think so, but I'm not sure.
  • [9:00] Zero Linden: Yuu - I think all tools do IK, but the use it to compute the results, and the export format loses all that info
  • [9:00] Dyne Talamasca: nods
  • [9:00] Morgaine Dinova: MIME type? /me checks calendar, though April 1st already passed ;-)
  • [9:00] Zero Linden: Some of them have private formats that store the IK control inputs....
  • [9:01] Zero Linden: But even if we factor it out - we'd have to do type negotiation and servers would probably all need to be able to down-grade on the fly to the common set
  • [9:01] Zero Linden: OKay- topic 2
  • [9:01] Zero Linden: Topology
  • [9:01] Morgaine Dinova: I wonder if any client hackers have factored out the SL av system from the client.
  • [9:01] Lillie Yifu: But that is a matter of not having a target format....
  • [9:02] Morgaine Dinova: Q1: how hardwired is the "gridiness"?
  • [9:02] Zero Linden: So - there is one end of the specturm
  • [9:02] Zero Linden: when you connect to a region
  • [9:03] Zha Ewry: listens quitely
  • [9:03] Zero Linden: the viewer gets a Tensor that describes the topology of the 3D space, and hence tells it how to interpret the 3D coordinates of every object
  • [9:03] Zero Linden: and also the bounding volume of that region
  • [9:03] Lillie Yifu: giggles
  • [9:03] Zero Linden: and tthen if the viewer wanted to look (or enter) space beyond that bounding volume, it would have to send a frustrum
  • [9:04] Zero Linden: to the server, and receive a set of possible multiple other adjacent regions to contact to fill that part of space
  • [9:04] Morgaine Dinova: But today's region doesn't have a bounding volume, just a bounding surface. It's inifinitely high :-)
  • [9:04] Zero Linden: And ignoring the potential problems with adjacent regions report Tensors and bounding volumes that conflict,
  • [9:04] Zero Linden: this would provide a totally open, and arbitrary topology
  • [9:05] Saijanai Kuhn: glances at his ever-lengthening leg...
  • [9:05] Zero Linden: Morgaine - in the generality I described, we'd have to be comfortable with bounds being infinite in some dimentions
  • [9:05] Zero Linden: after all - that tensor can describe a pretty bizarre shaped space
  • [9:05] Lillie Yifu: hmmmmmm
  • [9:05] Zero Linden: one might even have to worry about spaces with no bound (i.e. that "wrap")
  • [9:06] Morgaine Dinova: When I park my orbital platform region above Grasmere, I don't want to be contained within Grasmere space just because SL provides no upper bound ;-)
  • [9:06] Zero Linden: Well, I think, even in this model, it would have to be SL's choice to use all the space above or not.
  • [9:06] Zero Linden: for this region, that is
  • [9:06] Rex Cronon: u could use another dimension, moragaine:)
  • [9:07] Saijanai Kuhn: My solution is simply to assume that "grids" that use different topologies will either be TP-only to get there, or will provide boundry sims that act as a visual buffer to the rest of the topology
  • [9:07] Zero Linden: of course, this fully general model has many many difficulties
  • [9:07] Zero Linden: first and foremost it would be really expensive to manage on both viewer and server
  • [9:07] Morgaine Dinova: Well that's gotta change --- you can't claim infinite space in 3D, because space is exclusive, not shareable.
  • [9:07] Infinity Linden: thinks about issues with n-many adjacent regions to communicate with, where n is some arbitrarially large number
  • [9:07] Zero Linden: second, all manner of tool kits, APIs, frameworks, libraries, etc. wouldn't be able to handle such a thing
  • [9:08] Dyne Talamasca: ponders sims that are 256 meters sharing a border with 512 meter sims ... scaled to half size.
  • [9:08] Zero Linden: and, one might even argue that most users couldn't make heads or tails of it
  • [9:09] lonetorus Habilis: zero, will the teen grid be seperated from the main grid? (as i understand it, the two share gloabl grid positions, and there are roumers that teen avies have been teleporting directly to maingrid)
  • [9:09] Morgaine Dinova: Zero: most users are perfectly happy with the topological constraints of RL ... and owning a space station that isn't part of the country below it is very natural.
  • [9:09] Zero Linden: So, before we tackle infinite heights, let's talk about Cartesian space
  • [9:09] Lillie Yifu: As in the grid is flat, and htat isn't necessariy what people want?
  • [9:10] Morgaine Dinova: I am talking about cartesian ... but the world happens to be spherical, not Flatland like in SL :-)
  • [9:10] Zero Linden: quick: Yes, the teen grid and the main grid aren't actually separate grids in the sense of separate coordiante space, or even separate infrastructure
  • [9:10] Zero Linden: Well, if we are comparing things to the world
  • [9:10] Zero Linden: then, at the scale of the extent of SL, we, as humans, primarily deal with such things as being flatland
  • [9:11] Zero Linden: Remember, as big as SL is - it still only the size of a medium city
  • [9:11] Zero Linden: That there is curvature between, say, New York and San Francisco
  • [9:11] Zero Linden: only really matters if you are building a Burrito Tunnel
  • [9:12] Zero Linden: [1]
  • [9:12] Morgaine Dinova: Zero: so at present it can afford to approximate to Flatland. However, remember where we're heading, the scaling numbers. It will not be able to be Flatland for long.
  • [9:13] Saijanai Kuhn: i don't think scaling is the issue, MOrgaine. You could have a round world the size of a single sim. Look at the illustrations of The LIttle Prince
  • [9:13] Rex Cronon: sl could become a planete, maybe even a solar system:)
  • [9:13] Morgaine Dinova: And I don;t think it should be a Flatland at all anyway, but a normal piece of planetary surface.
  • [9:13] Infinity Linden: or a dyson sphere
  • [9:13] Zero Linden: Oh - I'm not sure I see that - again - the fact that earth is round and that there is curvature only affects a very small amount of human endevour, and mostly they have to work around it
  • [9:13] Morgaine Dinova: Sai: indeed, size isn't the issue. Topology is
  • [9:14] Rex Cronon: planet SL?
  • [9:14] Saijanai Kuhn: yes, so the number of sims isn't the issue. The design of the topology is. The question you're really asking:
  • [9:14] Zero Linden: Okay - so then, I'd look for the advantages, not based on size, to a spherical (and hence bounded) map space
  • [9:14] Lillie Yifu: Wehther SL should be round or flat is less important than whether the protocol should be
  • [9:14] Lillie Yifu: right now we are dealing with small scales and low speeds, but that isn't necesarily wt people will want for long
  • [9:14] Zero Linden: Oh, I'm pretty sure the protocol will be lumpy! :-)
  • [9:15] Morgaine Dinova: Yep, SL should be a planet. Other worlds will be planets after all (lots of people want space worlds), so in due course SL's Flatland will be pretty retro.
  • [9:15] Saijanai Kuhn: can we create a generic way (sorta generic) to allow for different topologies in different "grids" that can be used by the general SL viewer?
  • [9:15] Lillie Yifu: when I got here the first thing I wondered about was wehtehr anyone role played an airline.
  • [9:16] Morgaine Dinova: Zero+Lillie: well that's a serious question. Is the protocol going to hardwire in the notion of 2D? I hope not, else it's going to get forked.
  • [9:16] Dyne Talamasca: If you allow 3D coordinates, most topologies can follow from that. At least, most ways of representing them in a space we can comprehend.
  • [9:17] Morgaine Dinova: Dyne: agreed. The RL is 3D, so that should be the base.
  • [9:17] Zero Linden: Well - In the absence of clear value for the complexities of spherical topology ( regions aren't rectangles, for example)
  • [9:17] Saijanai Kuhn: Morgaine, I think it inveitbale. Rather than try to create a one-size fits all protocol for viewers, create a way of the viewer and VW to negotiate what is needed to properly deal with the toplogy of a given world
  • [9:17] Zero Linden: I don't see why the protocol would go to the effort to support it
  • [9:18] Saijanai Kuhn: Just have a toplogy index with 0 being the standard SL toplogy.
  • [9:18] Saijanai Kuhn: anything non-zer needs a special viewer
  • [9:18] Zero Linden: I suppose torroidal systems could be easily accomodated (by connecting eastern edge to western, northern to southern)
  • [9:18] Morgaine Dinova: Zero: it's because we're making the protocol for all worlds, not just for the worlds of SL's preferred geographic structure.
  • [9:19] Infinity Linden: but our polar reaches would wind up being smaller than our equatorial regions
  • [9:19] Saijanai Kuhn: MOrgaine, but LL can't be expected to predict all needs. Just add a 32-bit value that signals to the viewer that there might be some special need and forget about it
  • [9:19] Zero Linden: Morgaine at any world scale - all regions of the order of 65k sq. m. are going to appear flat
  • [9:19] Zero Linden: it is only about placement relative to larger space
  • [9:19] Morgaine Dinova: Sai: no prediction needed. RL is a 3D space. It's not a way out prediction that attached worlds will want to be 3D. It's a certainty.
  • [9:20] Zero Linden: but if you really think you need to represent spheres, then, as map makers have struggled with, it all breaks down at the poles
  • [9:20] Saijanai Kuhn: someone who comes up with a new toplogy can register their own non-zero ID number and viewer plugin to handle it. End of story
  • [9:20] Dyne Talamasca: is mostly just thinking of the ability to have a voxel lattice rather than a pixel grid.
  • [9:20] Zero Linden: Okay - I'm going to pause this here
  • [9:20] Zero Linden: and pick up the next issue
  • [9:21] Zero Linden: Denying Caps
  • [9:21] Morgaine Dinova: Zero: which are the places in the protocol where topology matters? The easy one is coordinates ... well let's at least ensure that no 2D notions are hardwired there.
  • [9:21] Zero Linden: who was that? Rex?
  • [9:21] Leffard Lassard: Me.
  • [9:21] Rex Cronon: downloading priority for textures/sculpties?
  • [9:21] Zero Linden: Go!
  • [9:21] Leffard Lassard: Yeah, my question is, are not granted caps requested from a seed cap simply igrnored, left out?
  • [9:21] Zero Linden: That was the (is the) plan
  • [9:22] Leffard Lassard: I think it could be of advantage to still give out a reference to get some sort of error value with it.
  • [9:22] Zero Linden: do you think we need a reson code?
  • [9:22] Zero Linden: we could substitute a "standard error" block
  • [9:22] Leffard Lassard: A cap may be not allowed, not implemented or temporarily down. All sorts of different reasons a cap cant be granted.
  • [9:22] Zero Linden: but I think we should allow sims to just deny the request
  • [9:23] Zero Linden: Usually, if a service is temporarily down, one still grants the cap to it, and lets the cap return the 500 level error
  • [9:23] Zero Linden: (or 300)
  • [9:23] Zero Linden: But, I could see cases....
  • [9:23] Leffard Lassard: And the viewer may handle that differently with a proper error status of a cap.
  • [9:24] Zha Ewry: I think being able to distinguish the various cases has merit
  • [9:24] Zero Linden: I sort of hate to re-encapsulate the whole 2xx, 3xx, 4xx, 5xx scheme into each simple return value, though
  • [9:24] Morgaine Dinova: Leffard: sounds like your code has hit its head against that already?
  • [9:25] Zero Linden: And I suspect for hard errors, it is going to be hard for the viewer to decode that into meaningful errors for the user....
  • [9:25] Zero Linden: BUT
  • [9:25] Leffard Lassard: I could think of always granting an url but it could be pointing to a 3xx or 4xx resource to give out further information.
  • [9:25] Zero Linden: we could do if the value is a URL, success
  • [9:25] Zero Linden: else it is a "retry later", or "error, code, user-message"
  • [9:25] Zero Linden: (not as strings, but as an error structure)
  • [9:26] Zero Linden: (sort of wishes that LLSD had error as fundimental thing.... but that would just make encoding in JSON that much harder.... sigh)
  • [9:26] Leffard Lassard: Perhaps, like ws-* has an error message possiblity.
  • [9:27] Zero Linden: (My last personal research project had errors and fundimental values, represented in the language with the token: !!! )
  • [9:27] Morgaine Dinova: We were talking about that on Tuesday. Don't make these things HTTP errors (unless that is failing), but HTTP success + an LLSD error structure.
  • [9:27] Zero Linden: Oh yes -
  • [9:28] Zero Linden: I recently got into a whole discussion at work for another purpose, trying to tease out when it was appropriate for a service to map it's error into the HTTP status codes vs. when it should return a 200 and have internal error information in the result body
  • [9:28] Morgaine Dinova: And the consensus?
  • [9:28] Zero Linden: The key is thinking of the HTTP transport needs to react to the error
  • [9:29] Morgaine Dinova: s/of/if/ ?
  • [9:29] Zero Linden: for example, many kinds of error SHOULD return as HTTP 404, because you want any intermediate caches and proxies to know that it happened
  • [9:29] Zha Ewry: Keeping in mind the lSO stack's proven good properites, please
  • [9:29] Zero Linden: er yes, thinking if...
  • [9:29] Morgaine Dinova: k
  • [9:29] Zha Ewry: ie surfacing various things at the proper layer proves vital in the long run
  • [9:29] Zero Linden: The pitfall is that, probably for historical reasons, there are some HTTP status codes that look very upper level protocol-ish
  • [9:30] Zero Linden: 402 Payment Required
  • [9:30] Morgaine Dinova: Hehehehe. Oh dear
  • [9:30] Zero Linden: Now, we shouldn't, for example, return that when the avatar tries to simply take an object that needs to be bought
  • [9:31] Morgaine Dinova: But we don't need to preserve the bad choices of the past
  • [9:31] Infinity Linden: seems the semantics of a 402 at that level would mean you have to pay to use our http service, irrespective of what's on top of it...
  • [9:31] Morgaine Dinova: Infinity: yes
  • [9:31] Lillie Yifu: hmmmm don't hardwire http...
  • [9:31] Zero Linden: Perhaps - the standard is rather mum on the whole code
  • [9:32] Zero Linden: "This code is reserved for future use."
  • [9:32] Zero Linden: Lillie - we don't
  • [9:32] Zero Linden: the spec tries to deine a semantic of "accessing a resource" that is sufficiently independent of HTTP
  • [9:32] Zero Linden: that it could be mapped ontop of another tansport
  • [9:32] Zero Linden: transport
  • [9:33] Zero Linden: but it DOES make use of REST style semantics, so it looks awfully comfortable on top of HTTP
  • [9:33] Zero Linden: speaking of...
  • [9:33] Zero Linden: this segues into my topic
  • [9:34] Zero Linden: I've been thinking about last sessions discussion of reverse HTTP
  • [9:34] Zero Linden: and just want to point people's eyeballs at the HTTP spec's defintion of
  • [9:34] Zero Linden: the status code 101 Switching Protocols
  • [9:34] Zero Linden: and the header Upgrade:
  • [9:34] Zero Linden: okay
  • [9:34] Zero Linden: thanks all
  • [9:34] Zero Linden: it is 9:30.... gotta run
  • [9:34] Morgaine Dinova: Cheers Zero
  • [9:34] Rex Cronon: bye zero
  • [9:34] Taff Nouvelle: Bye
  • [9:34] Infinity Linden: yea!
  • [9:35] Infinity Linden: thx
  • [9:35] Infinity Linden: whoa.. he leaves quickly
  • [9:35] Dyne Talamasca: nods
  • [9:35] Morgaine Dinova: Aye. Turns into a pumpkin otherwise ;-)
  • [9:35] Infinity Linden: but I too have to run... thanks everyone for letting me sit in!
  • [9:35] Rex Cronon: bye infinity
  • [9:35] Saijanai Kuhn: ah well, shudda gotten my item higher on the agenda
  • [9:36] Morgaine Dinova: Nice to see you Infinity
  • [9:36] Infinity Linden: it's great to hear resident's concerns directly from the source
  • [9:36] Infinity Linden: cheers, al!
  • [9:36] Morgaine Dinova: waves
  • [9:36] Morgaine Dinova: Good session
  • [9:37] Kerry Giha: yes
  • [9:37] Zillion Blackadder: Thanks, all - most interesting
Personal tools