User:Zero Linden/Office Hours/2009 Jan 13

• [13:00] Rex Cronon: hi everybody
• [13:00] Lim Catteneo: hi Rex :)
• [13:00] Morgaine Dinova: Hola Rex
• [13:01] [[User:emoteur [scriptemoteur]|emoteur [scriptemoteur]]]: Script run-time error
• [13:01] [[User:emoteur [scriptemoteur]|emoteur [scriptemoteur]]]: Stack-Heap Collision
• [13:01] Rex Cronon: hiii
• [13:01] Skills Hak: hi guys
• [13:02] Morgaine Dinova: Hiya Whump!
• [13:02] Rex Cronon: lol. a pixelated kitty:)
• [13:02] Morgaine Dinova: chuckles at the thought of a robot taking a seat :-)
• [13:02] Skills Hak: 8 bit in a 64bit world
• [13:02] Whump Linden: 8 bit culture for the win, there Skills.
• [13:02] Rex Cronon: nice:)
• [13:03] Skills Hak: \o/
• [13:03] Saijanai Kuhn: Whump and anyone else that missed the meeting this morning: https://wiki.secondlife.com/wiki/AW_Groupies/Chat_Logs/AWGroupies-2009-01-13
• [13:04] Morgaine Dinova: Skills, you have too much depth :-)
• [13:04] Morgaine Dinova: Wow, vicinity chat lag
• [13:04] Skills Hak: x)
• [13:04] Saijanai Kuhn: morning teacher (afternoon)
• [13:05] Morgaine Dinova: 'Afternoon, Zero ;-)
• [13:05] Zero Linden: hello all
• [13:05] Saijanai Kuhn: and repeating for the latecomers: https://wiki.secondlife.com/wiki/AW_Groupies/Chat_Logs/AWGroupies-2009-01-13
• [13:05] Rex Cronon: hello zero
• [13:05] Lim Catteneo: hi
• [13:06] Zero Linden: Nice group title, Skills
• [13:06] Whump Linden: thanks Saijanai
• [13:06] Skills Hak: hallo
• [13:06] Skills Hak: ty
• [13:06] Morgaine Dinova: Yeah, seeing a lot of that these days. Maybe the tag should be multimedia :-)
• [13:07] Zero Linden: When I was at Go Corporation, I made the argument that document names should be an instance of the formatted text class, rather than string
• [13:08] Lim Catteneo: lol
• [13:08] Skills Hak: hee
• [13:08] Zero Linden: it would have led to ability to embed documents in the title of a document !
• [13:08] Zero Linden: We didn't go for it, though. Just as well, the OS was hell-a-slow as it was without having to do formatted text for every document listed
• [13:09] Zero Linden: So - welcome to my office hours.
• [13:09] Whump Linden: but now we have multimedia previews of documents in the Mac OS finder.
• [13:09] Lim Catteneo: zore must've been really popular with the coders :P
• [13:09] XerxesTiny.LITTLE BEE.Head: Touched.
• [13:09] XerxesTiny.LITTLE BEE.Head: Touched.
• [13:09] Zero Linden: Agenda items?
• [13:09] Saijanai Kuhn: leaked memos?
• [13:09] lonetorus Habilis: news on http transport?
• [13:10] Morgaine Dinova: Zero: sounds like a cool idea :-)
• [13:10] Temporal Mitra: zero...are you the one working one httpIN?
• [13:10] Zero Linden: Lim - I *was* one of the coders -- I was on the Application Framework team (which included PenPoint's equivalent of the Finder) -- there were just three of us - architects/desingers/coders all rolled into one
• [13:10] Zha Ewry: Mapping IIM into Caps?
• [13:10] Zero Linden: Temporal - I'm not, Kelly Linden is the main engineer on HTTP-In
• [13:10] Zero Linden: but I'm really looking forward to its deployment
• [13:11] Saijanai Kuhn: Keey was on paternity leave last month
• [13:11] Temporal Mitra: agreed..it's gonna change a lot of things in sl
• [13:11] Saijanai Kuhn: kelley*
• [13:11] XerxesTiny.LITTLE BEE.Head: Touched.
• [13:11] XerxesTiny.LITTLE BEE.Head: Touched.
• [13:11] Zero Linden: It will allw us to eventually deprecate XML-RPC
• [13:11] lonetorus Habilis: \o/
• [13:11] Zero Linden: and perhaps even object e-mail
• [13:11] Zero Linden: both of which are kind of untenable solutions when scaled
• [13:11] Elbereth Witte: I think email will depreciate itsself for most apps
• [13:12] Saijanai Kuhn: still no notecards rezzed on demand though
• [13:12] Morgaine Dinova: LOL lone :-)
• [13:12] Zero Linden: (funny to say that about e-mail, eh?)
• [13:12] Lim Catteneo: please don't :) i love object email :)
• [13:12] Temporal Mitra: would suggest strongly that you not depreciate either one of them....
• [13:12] Zero Linden: Well - by deprecate, of course I mean "stop encouraging new use" -- we'll be supporting existing content for a long time
• [13:12] Zero Linden: Unles you were making a spelling joke....
• [13:13] Zero Linden:  :-)
• [13:13] Temporal Mitra: most of us tend to build in redundency in our communcations ...for times when LL is not as perfect in all the ways it would like to be
• [13:13] Morgaine Dinova: Skills sitting on sofa is even more bizarre than Whump ;-)
• [13:13] Zero Linden: well, http-in makes object e-mail look slow, unreliable and clunky
• [13:13] Zero Linden: (except for the use case of objects sending e-mail out to people)
• [13:13] Imaze Rhiano: agenda?
• [13:13] Saijanai Kuhn: managed to fake an agent domain login with it. it lacks non-plain-text headers though
• [13:13] Lim Catteneo: but has a lot of problems, changing urls on every sim restarte, etc
• [13:13] Lim Catteneo: lot of clunky code to work around that
• [13:14] Temporal Mitra: agreed...most anything would...but recalls that not all functions are 100% reliable 100% of the time...and so prefers to have backups
• [13:14] Whump Linden: / Morgaine, it's hard to do fine-grained hovering in a covered area.
• [13:14] Zero Linden: Yes - agenda items?
• [13:14] Morgaine Dinova: Hehe
• [13:14] Lim Catteneo: Migration of IIM UDP packet to CAPS was what Zha suggested
• [13:14] Temporal Mitra: changing urls on sim restarts is problematical...but you can make a cascading keyless system which would allow even huds to use http
• [13:15] Saijanai Kuhn: right, and a discussion of what two-way caps comunication would look like
• [13:15] lonetorus Habilis: zero, i hear talk about the posibility to attach sims run by oneself to sl grid for a free, is there any truth in that, and if so, what main obstacles are there before it might be available?
• [13:15] lonetorus Habilis: fee even ;)
• [13:16] Zero Linden: we can talk about migration of UDP -
• [13:16] Zero Linden: is two-way caps different than the event queue discussion of yore?
• [13:16] Saijanai Kuhn: well, insomuch as the client needs to be able to send outgoing IM via cap
• [13:17] Zero Linden: lontorus - the AWG's work on OGP is leading to such a future - no date set - we ran an open trial this late Summer/Fall and showed that it could be done
• [13:17] Skills Hak: different grids i think lone
• [13:17] Zero Linden: okay - once/twice/thrice -- sold
• [13:17] Zero Linden: Zha - UDP over .... ?
• [13:18] Saijanai Kuhn: IIM two way communications with a connection point (or poitns) set up by the AD
• [13:18] Lim Catteneo: moving ImprovedInstantMessage over to caps
• [13:18] Zero Linden: I can give an overview of what is in the viewer now in that direction - and how it might point to both OGP's integration of UDP mesages and things like bi-directional messages
• [13:19] Zero Linden: Rightn now each UDP message has a name, and one or more blocks where each block has a name and one or more fields - the lat of which can be repeating
• [13:20] Zero Linden: of course, this is all binary encoded in UDP -- with both sides having a shared map of small integers to names of components and messages
• [13:20] Zero Linden: (the infamous Message Template)
• [13:20] Saijanai Kuhn: [1]
• [13:20] Zha Ewry: Is it actually infamous?
• [13:20] Saijanai Kuhn: the nastiest one I've had to deal with so far is ObjectUpdate
• [13:21] Saijanai Kuhn: asmd Catherine Pfeiffer wrote a patch to the viewer to put that into LLSD/XML form
• [13:21] Zero Linden: Each such message can be equivalently cast as an POST to a resource with the name of the message, and a body which is an LLSD representation of the data
• [13:22] Dahlia Trimble: wasnt that ObjectAdd?
• [13:22] Zero Linden: Yes, some messages - ObjectUpdate, for example, has a "binary blob" data type
• [13:22] Saijanai Kuhn: Dahlia, right, my bad
• [13:22] Zha Ewry: Which sepertes out allthe bookkeeping, and lets you look at just the data flow, in theory
• [13:22] Lim Catteneo: yeah, we have seen that with EnableSimulator message being moved over to caps without client code change
• [13:23] Zero Linden: while that can be represented in LLSD, as a binary element, it means that the internals are a message-specific binary encoding, which, sigh stays with us
• [13:23] Saijanai Kuhn: Zero this much I understand. However, for ungoing message sending like with IM, there's no defined packet order or whatever. Do we just assume that its always received properly?
• [13:24] Zero Linden: Sai - you mean to tell me you've never whitnessed IM confusion in SL?
• [13:24] Zero Linden:  :-)
• [13:24] Saijanai Kuhn: ,never
• [13:24] Saijanai Kuhn: no
• [13:24] Nitram Wei: beezarre
• [13:24] Dahlia Trimble: IMs can be quite confusing in SL™ ;)
• [13:25] Zero Linden: well...... it happens, pal! Like Einstein Linden said: causality is relative.... relative to network lag!
• [13:25] Morgaine Dinova: Hehe
• [13:25] Saijanai Kuhn: I guess what I'm saying is that there's no ACK defined for the message POSTed to a cap.
• [13:25] Zero Linden: sure there is
• [13:26] Zero Linden: the 200 or 201
• [13:26] Lim Catteneo: there are acks
• [13:26] Saijanai Kuhn: ok, so just use the built in syntax... nothing special.
• [13:26] Zero Linden: return code is ack. that the message has been received by the remote system and accepted for processing
• [13:27] Zero Linden: there is no higher level protocol ack -- which for IM would be something like: "I ACK that the message was forwarded to the user's viewer"
• [13:27] Zero Linden: mind you, for increasing cost, you could make that application level ACK mean different things: "I ACK that the message was drawn on the user's screen"
• [13:27] Zero Linden: "I ACK that the user clicked 'OK, I've read this' for this message"
• [13:27] Zha Ewry: I ack that the user read the message and sent back a snippy reply
• [13:28] Morgaine Dinova: Nobody complains about the order in which messages sent within the same 100ms are distributed. It's not simultaneity that's demanded, just a reasonable approximation :-)
• [13:28] Saijanai Kuhn: well, we DO get error messages claiming that message not sent...
• [13:28] Saijanai Kuhn: followed in general by the message appearing
• [13:28] Zero Linden: but for some applications, the semantics of the system don't require this kind of ACK
• [13:28] Zero Linden: in particular, IM seems to be its own ACK!
• [13:28] Lim Catteneo: hm I seem to recall an explicit ACK packet sent back via event queue for each recieved message. And I don't meant ACK by http return code
• [13:29] Saijanai Kuhn: that's for the event queue get ack itself
• [13:29] Zero Linden: AH - well - the ACK in the Event Queue -*IS* a proxy for the HTTP 200
• [13:29] Zha Ewry: cringes at that last
• [13:29] Zero Linden: see, the ack in the Event Queue request is really the *response* of the simulated reverse HTTP flow
• [13:29] Zha Ewry: I mean I know what you mean, but ick
• [13:30] Zero Linden: Think of the Event Queue as a transport for HTTP in the reverse direction --- only as currently deployed it doesn't ahve full HTTP semantics (no headers, and no response body)
• [13:30] Morgaine Dinova: Sai: The successful delivery of an IM after having received a failure message is an important fact --- it must indicate a code or design flaw, and easily repeatable.
• [13:30] Saijanai Kuhn: I gues what I lack is the meta format for the IIM or other packet. Is there something that should be included with it to let the system respond differently than with a normal response to the long poll?
• [13:31] XerxesTiny.LITTLE BEE.Head: Touched.
• [13:31] XerxesTiny.LITTLE BEE.Head: Touched.
• [13:31] Saijanai Kuhn: ie we send an ACK to request info from the EVent Queue. How do we send data to the event queue as data
• [13:32] Zero Linden: oh - you mean run arbitrary messages from viewer to simulator?
• [13:32] Saijanai Kuhn: right
• [13:32] Zero Linden: Aha
• [13:32] Saijanai Kuhn: sighs in relief
• [13:32] Zero Linden: well, in a perfect world, each such message endpoint (ending at the simulator) should indeed have a cap
• [13:32] Zero Linden: SO
• [13:32] Zero Linden: if the viewr wants to send messages to the resource ImprovedInstantMessage
• [13:33] Zero Linden: it needs to request that CAP from the seed cap
• [13:33] Zero Linden: and then use that CAP as the URL to POST to -- simply posting the body of the message
• [13:33] Zero Linden: the "name" of the message is the URL
• [13:33] Saijanai Kuhn: or whatever cruft is required for IIM interface at this point
• [13:33] Zero Linden: or you can think of the URL as the "binding" of a message name (ImprovedInstantMessage) and a particular object (this sim)
• [13:34] Zero Linden: (Python has a name for this thing, doesn't it? In C++ they don't exist)
• [13:34] Saijanai Kuhn: key?
• [13:35] Saijanai Kuhn: dicionary["mykey"]
• [13:35] XerxesTiny.LITTLE BEE.Head: Touched.
• [13:35] XerxesTiny.LITTLE BEE.Head: Touched.
• [13:36] Zero Linden: no no ---
• [13:36] Saijanai Kuhn: ...
• [13:36] Zero Linden: like if you say
• [13:37] Zero Linden: d = datetime.datetime.now()
• [13:37] Zero Linden: d.isoformat()
• [13:37] Zero Linden: calls isoformat() on that particular d
• [13:37] Zero Linden: but
• [13:37] Lim Catteneo: hello Eddy with no last name :P
• [13:37] Zero Linden: f = d.isoformat
• [13:37] Saijanai Kuhn: oh right. Not sure how what that is called
• [13:37] Zha Ewry: Ninja Eddy stryker ;)
• [13:37] Zero Linden: sets f to a thing that binds the message name 'isoformat' to that particular object, d
• [13:37] Saijanai Kuhn: side effect of everything being a python object
• [13:37] Lim Catteneo: :P
• [13:37] Eddy Stryker: hello Lim Catteneo
• [13:38] Zero Linden: such that if you call f(), you are calling isoformat on d
• [13:38] Zero Linden: f is like a cap
• [13:38] Saijanai Kuhn: OK
• [13:38] Lim Catteneo: is that for the member of the royal family? :P they seem to hate last names
• [13:38] Zero Linden: or rathe a cap is like f: binding a particular message, say ImprovedInstantMessage, with a particular endpoint, say the simulator
• [13:39] Saijanai Kuhn: KK, so, assuming one message type per cap, we just send it the "raw" LLSD/XML and are done...?
• [13:39] Zero Linden: yes
• [13:39] Zero Linden: NOW
• [13:39] Morgaine Dinova: Nice 2-line tag Eddy --- you could make it say M Linden and raise mayhem :-)
• [13:40] Skills Hak: heeh
• [13:40] Saijanai Kuhn: no meta structure like {"IIM": {iim data}}
• [13:40] Whump Linden: / probably should file a jira about that... but nice hack, Eddy :)
• [13:40] Skills Hak: its a group tag removing the LastName string
• [13:40] Eddy Stryker: zero: but a cap binds more than just that, it's also the current user session. when you come back and ask for that same cap on the same simulator in a new session, it's not the same cap
• [13:40] Skills Hak: another thing that needs serverside checking
• [13:40] Lim Catteneo: whump: there is a SEC- for it already :P
• [13:40] Zero Linden: Sai - right, the message name is implicit in the cap -- just like 'isoformat' was implicit in f
• [13:41] Zha Ewry: Its vert much a temporary bidning, yes
• [13:41] Eddy Stryker: morgaine: good call ;)
• [13:41] Whump Linden: Thanks, Lim.
• [13:41] Zero Linden: Eddy - to a degree that *may* be so - you can't rely on it
• [13:41] Morgaine Dinova: Bah Whump, no nerfing whenever residents get clever :-)
• [13:42] Zero Linden: and yes - on the simulator side, plenty of stuff might be bound up with the cap -- the agent ID of the requestor (and hence future invoker of the cap) and perhaps authorization decision information
• [13:42] Zha Ewry: its in the funny case wher eyou have to assume i's not stable but it might ne
• [13:42] Eddy Stryker: zero: you can't rely on it not being the same? hopefully you shouldn't ever have to rely on that
• [13:43] Saijanai Kuhn: sounds like you cant rely on relying on it not being the same...
• [13:43] Zha Ewry: Depending on it changing would be as bad as depending on it being stable I expect
• [13:43] Zero Linden: right - Eddy - but ya know, unless one says so explicitly, people come to rely on all sorts of things you didn't expect them to
• [13:43] Eddy Stryker: hehe true
• [13:43] Saijanai Kuhn: must.should/can/etc?
• [13:43] Nitram Wei: i rely on being welcome here inspite of being a bug?
• [13:44] Eddy Stryker: sounds like a "should"
• [13:44] Zha Ewry: Should
• [13:44] Nitram Wei:  ?
• [13:44] Zha Ewry: If its a must or shall
• [13:44] Nitram Wei: explain
• [13:44] Zero Linden: so - once and for all - the cap is an opaque URL - you can pull apart the scheme, host and port (as you need to to ensure you can invoke it), you can check that the protocol is HTTP or HTTPS, and that the host isn't localhost or an alias of yourself
• [13:44] Zha Ewry: then the beheavior is very constrained
• [13:44] Zha Ewry: You can't look at the rest meaningfully
• [13:44] Morgaine Dinova: Good
• [13:45] Saijanai Kuhn: right. I was assuming an overloaded POST, just as the response for EQG is overloaded
• [13:45] Zero Linden: Nitram - you're the bee in our bonnet, of course you can assume you're welcome here!
• [13:45] Saijanai Kuhn: but if its one message type per CAP, there's no problems
• [13:45] Nitram Wei: i thank you
• [13:45] Zha Ewry: And far less visually migraine inducing than many
• [13:46] Eddy Stryker: zha: can't look at the rest, or the REST?
• [13:46] Nitram Wei: or as my sort use to say: i stinhz you very much
• [13:46] Zero Linden: NOW - there *could* be a generic resource - say ReceiveViewerMessage
• [13:46] Nitram Wei: *stingz
• [13:46] Zha Ewry: can't look to my left
• [13:46] Nitram Wei: u may click my head for free now
• [13:46] Zero Linden: that takes a message body that conforms to: { message: string, body: any }
• [13:46] Eddy Stryker: which brings up a good point, when you request a capability and it is granted, you have no idea which HTTP verbs were granted to you. you just have to guess and check
• [13:46] Zha Ewry: Lone is pretty literally migraine inducing
• [13:47] Zero Linden: and *THAT* could, when invoked, unpack it's contents and re-inject the body into the right message handler in the simulator
• [13:47] Zero Linden: and this would allow the viewer to get one and only one CAP for most communication to the simulator
• [13:47] Zero Linden: this isn't long term desirable
• [13:47] Zha Ewry: Sure, but it would be REST hostile
• [13:47] Zero Linden: BUT - it can allow us to migrate lots of old UDP messages to TCP really quickly
• [13:48] Morgaine Dinova: What about the identity semantic? Can two URLs be assumed to always denote different resources if they are lexically different?
• [13:48] Zha Ewry: CAPS can be marginally REST hostile, because they do funny thingt to resource naming
• [13:49] Saijanai Kuhn: Zero there's one place where such a beast makes a lot of sense and that is for ObjectUpdate, where some things, like floating text, require you to send the entire packet per update even if its only 5 bytes that changed
• [13:49] Eddy Stryker: morgaine, wouldn't that depend on the definition of "different"? if two different avatars request a cap for IM on Grasmere, they get different capability URLs pointing to the same underlying resource, but with different session information attached to each
• [13:49] Zha Ewry: /or the same one
• [13:49] Zha Ewry: That's a sim side choice, I think
• [13:49] Zha Ewry: You might conclude a cap which reurns public data, can be a stable public gettable cap
• [13:49] Zha Ewry: and hand it to lost of people
• Preview Grid (Aditi) (Starts in 10 minutes)
• [13:50] Zha Ewry: Lots too
• [13:50] Morgaine Dinova: Eddy: ok, so the answer is No then --- not even non-identity can be assumed if URLs differ.
• [13:50] Morgaine Dinova: Assume nothing! ;-)
• [13:50] Eddy Stryker: Zha: which would preserve the last ~20 years of progress in web caching
• [13:51] Zha Ewry: nods
• [13:51] Zha Ewry: Yeps
• [13:51] Zha Ewry: when it is safe
• [13:51] Zha Ewry: and oppaque is oppaque
• [13:51] Elbereth Witte: assumption is bad, unless tahts part of the procedure :-)
• [13:51] Zha Ewry: You can't reason about it at all
• [13:52] Zha Ewry: The Globus Grid folks spent about a lifetime sorting that out at one point
• [13:52] Zha Ewry: and Oasis as wel
• [13:52] Zha Ewry: if you want to let the endpoint service manage its endpoints, and tell people they are oppaue, you have to mean it
• [13:53] Zero Linden: right - all of this is - well right
• [13:53] Zero Linden: as far as I can tell :-)
• [13:53] Morgaine Dinova: chuckles
• [13:53] Morgaine Dinova: Code!
• [13:55] Zha Ewry: wonders if her connection survived being unplugged
• [13:55] Lim Catteneo: it did
• [13:55] Ennui Nitschke: you're still here ;)
• [13:55] Zero Linden: it's TCP/IP! wooooot
• [13:55] Eddy Stryker: zha: yep, and you even have the same capabilities ;)
• [13:55] MT1337 Sinister: lights the blunt
• [13:56] Zero Linden: good thing those capabilities weren't based on established connections....
• [13:56] Goldie Katsu: udp to the rescue
• [13:56] Zha Ewry: it depends how quickly you notice the cable unplugging
• [13:56] Morgaine Dinova: looks sternly at Goldie :-)
• [13:56] Goldie Katsu: examines her shoes
• [13:56] Zero Linden: okay all - I've got a 2pm appointment to review some security fixes (woot!)
• [13:57] Goldie Katsu: w00t
• [13:57] Whump Linden: notes that MT1337 and I might ought to buy carbon particle credits.
• [13:57] Eddy Stryker: zha: sounds like a job for duct tape
• [13:57] Zero Linden: so - I can't be late to that...
• [13:57] Whump Linden: yes, take it easy all
• [13:57] Zha Ewry: Or remembering which cable is plugged into which hub
• [13:57] Saijanai Kuhn: KK and thanks for clearing up that minor (but essential) misunderstanding, Zero
• [13:57] Eddy Stryker: bye zero
• [13:57] Rex Cronon: bye zero
• [13:57] Zero Linden: thanks all for coming --
• [13:57] Nitram Wei: bye
• [13:57] Zero Linden: see ya next week....
• [13:57] Zha Ewry: i'm hoping to post
• [13:57] Goldie Katsu: Bye Zero.
• [13:57] Imaze Rhiano: bye zero
• [13:57] Zha Ewry: the secdurity scenarios int he next day or so
• [13:57] Ennui Nitschke: Have a good one Zero
• [13:57] Goldie Katsu: and I'm off as well.
• [13:57] Morgaine Dinova: See you all.
• [13:58] Ennui Nitschke: waves happily.