User:Which Linden/Office Hours/2008 Oct 16

• [11:05] Lalinda Lovell: yay
• [11:05] Which Linden: wewt
• [11:05] Gareth Ellison: sometimes i'll keep my eyes closed, other times i'll keep my eyes open and let the external environment get passively absorbed.... and which is here
• [11:05] Lalinda Lovell: my fave edible linden
• [11:05] Gareth Ellison: you just missed me and sai talking about meditation
• [11:05] Lalinda Lovell: which give up your life of sin and marry me
• [11:05] Which Linden: hah, well I hope it's been relaxing
• [11:06] Saijanai Kuhn: I wa pontificating. YOU were talking
• [11:06] Which Linden: um, that's ok
• [11:06] Gareth Ellison: heh
• [11:06] Gareth Ellison: which: teh agenda?
• [11:06] Saijanai Kuhn: brb
• [11:06] Lalinda Lovell: i want to wear a terracotta pot to be married in
• [11:06] Stefkaaa Shelman: who is german?
• [11:06] Which Linden: what did we talk about last time?
• [11:06] Lalinda Lovell: you need helpp stefkaa?
• [11:06] Which Linden: oh, right, caching issues that I have no idea about
• [11:07] Gareth Ellison: caching issues with all this HTTP trickery?
• [11:07] Gareth Ellison: use POST, be happy
• [11:07] Which Linden: no, viewer caching issues
• [11:07] Gareth Ellison: ah
• [11:07] Gareth Ellison: shuts up
• [11:07] Which Linden: I could talk about that
• [11:07] Which Linden: but yeah, http caching, that's an interesting topic
• [11:07] Which Linden: if you want
• [11:07] Which Linden: if my dang chat weren't out of order that would make sense
• [11:08] Gareth Ellison: not that interesting, fairly simple topic - not sure if there's any actual ISSUES with the HTTP trickery
• [11:08] Gareth Ellison: do share if there are.....
• [11:09] Which Linden: Well, it turns out that simple http caching is rarely the right thing for anything other than a simple html page
• [11:10] Saijanai Kuhn: imagines avatar movement sent via http and cached along the way...
• [11:10] Which Linden: heh exactly
• [11:10] Which Linden: much more useful are things like etags
• [11:10] Which Linden: and if-modified-since
• [11:10] Gareth Ellison: what conditions would we use a method other than POST and thus suffer from problems with cached changing data?
• [11:10] Which Linden: well, GETs, of course
• [11:10] Which Linden: e.g. getting your L$ balance
• [11:10] Which Linden: getting your profile
• [11:11] Which Linden: getting events; hell even retrieving IMs could be considered a GET
• [11:11] Gareth Ellison: no cache header, or last-modified header
• [11:11] Which Linden: gets vastly exceed any mutation operations we have
• [11:12] Which Linden: last-modified is sent down by the server, and the client can store that and when it wants to re-request that resource it sends if-modified-since with the previous last-modified header, and if the server determines that it has not been modified since then, it returns a 304
• [11:13] Which Linden: etags work the same way, except instead of a date they are a hash of the content
• [11:13] Which Linden: the theory is that it's much cheaper and bandwidth-friendly for the server to generate the 304 than to generate the actual resource
• [11:14] Gareth Ellison: i'm just wondering where in relation to SL we'd have HTTP caching problems
• [11:15] Which Linden: plenty of places relating to agent and group services
• [11:15] Which Linden: e.g. the list of the members in your group
• [11:15] Morgaine Dinova: Back. Hola Which :-)
• [11:16] Morgaine Dinova: Reading back
• [11:16] Which Linden: or the description of the group role, that could be cached
• [11:16] Which Linden: we largely sidestep these issues for now by not really caching
• [11:18] Which Linden: the cool thing I learned about recently is the if-match header
• [11:18] Which Linden: check this out: [1]
• [11:18] Which Linden: basically, what this is most useful for, is modifying data
• [11:18] Which Linden: let's say you're editing a wikipedia page
• [11:19] Which Linden: the way this works is, the server sends you a copy of the page, which you edit in your browser
• [11:19] Which Linden: then you PUT that copy back up to the server when you're done
• [11:19] Which Linden: but what happens if someone else modifies the document in that time?
• [11:19] Which Linden: you would clobber it if the server doesn't do any checking
• [11:20] Which Linden: mediawiki of course does do some sort of check, but the if-match header is a stanrdard way of doing so for every document in a REST web service
• [11:21] Which Linden: the way it works is, when you get the page to edit the first time, the server also sends down an etag that references the page at the time of editing
• [11:22] Which Linden: when you PUT your edited resource back, you also have an if-match header, with the etag you were given
• [11:22] Which Linden: and if the server, at the time of PUT, realizes that the etag is no longer the same (if, e.g. someone else edited the page during that time), it can reject you and force you to refresh to that person's version
• [11:24] Morgaine Dinova: That sounds good. It makes the server stateless and semantic-free, and lets the client decide on the expected semantic. But what happens if a client doesn't respect the expected semantic by not sending back the etag?
• [11:24] Which Linden: hmm... good thought
• [11:24] Which Linden: I guess the server has to reject it
• [11:25] Which Linden: well I guess it could go either way
• [11:25] Morgaine Dinova: Aha, so there's an "etag mandatory" property on a web object?
• [11:25] Which Linden: you would write the server so that it accepts requests with no if-match, and that wouldbe fine, but badly-behaved clients could stomp on things
• [11:25] Which Linden: or, yeah, you could just make the if-match header mandatory on PUTs
• [11:26] Morgaine Dinova: Is the etag opaque? Because if it's forgeable, then someone could manufacture an etag that means "override all".
• [11:26] Which Linden: it's opaque
• [11:26] Which Linden: I guess it depends on your implementation
• [11:27] Which Linden: but you'd have to be a fool to make it non-opaque
• [11:27] Morgaine Dinova: That could work, if it's opaque, and some objects can be flagged with "etag mandatory". Interesting.
• [11:28] Morgaine Dinova: So is that in libcurl?
• [11:29] Morgaine Dinova: And libwww and the others.
• [11:29] Which Linden: it's just a header
• [11:30] Which Linden: squid is aware of these headers, and uses them when checking to see whether it needs to refresh its cache
• [11:31] Which Linden: incidentally, the ability to be unforgeable is what gives etags an advantage over if-modified-since
• [11:31] Morgaine Dinova: Yeah
• [11:31] Which Linden: I don't know if libcurl keeps a cache of received etags and sends down if-none-match when repeating a GET
• [11:32] Which Linden: that would be the right thing to do, but.... it may rely on the application client to do that for it
• [11:32] Morgaine Dinova: It's good to know about that, cheers. No doubt it'll come up in the future when things stop working because of cache funnies.
• [11:33] Which Linden: hah, yeah
• [11:33] Which Linden: agent presence is cached, for example, and that did cause us some issues initially
• [11:33] Which Linden: (or, at least, lack of caching did)
• [11:33] Which Linden: but that was years ago
• [11:34] Morgaine Dinova: There's a lot of transparent proxies around in ISPs, it's a good thing that they only interfere on port 80, or it would be a disaster. :-)
• [11:34] Morgaine Dinova: Using the word "transparent" loosely. If only :-)
• [11:35] Which Linden: hah, yes, I've worked in places like that
• [11:36] Which Linden: that's one of the strengths of http -- if you do it right, you're making it easier to cope with things like caches and crap stuck in the middle
• [11:37] Which Linden: ok well I guess that was the http caching discussion
• [11:37] Which Linden: more to discuss there, or shall we move on?
• [11:37] Morgaine Dinova: Well stateless rocks full stop. Unfortunately, the <duck> Web-2.0 </duck> brigade seems to have forgotten what was good about HTTP.
• [11:37] Morgaine Dinova: Sure, move on :-)
• [11:39] Which Linden: well, you know, it's possible to do web-2.0 with stateless too
• [11:39] Which Linden: actually, it's easier
• [11:39] Morgaine Dinova: I get annoyed with every site that doesn't respect my browser's Back button ... and that's a lot of sites these days :-(
• [11:39] Which Linden: because you're explicitly expecting the client to keep state
• [11:39] Which Linden: yeah, but back button breakage != being stateful
• [11:39] Which Linden: it's kind of just a UI issue, really
• [11:40] Morgaine Dinova: Not really. If the server refuses access to prior state, there is no way in hell that the client can compensate, no matter how it's written.
• [11:41] Morgaine Dinova: Pretending the prior state is still accessible isn't a solution, since you then can't launch off prior state down another path.
• [11:42] Which Linden: I mean, it's the client's bad for not making it so that every url in your history points to a usable resource
• [11:43] Which Linden: it's possible to fake it, where clicking on an AJAX link adds an item to the browser's history
• [11:43] Morgaine Dinova: That's a terrible thing to say!!!! It's equivalent to "This app may be crap, but it's the browser's fault for making that obvious to people." :-))))
• [11:43] Which Linden: heh, no, it's still the app's fault
• [11:43] Which Linden: but it's not AJAX's fault
• [11:44] Morgaine Dinova: Absolutely not. If people want access to prior state, and it's a reasonable thing to want but the app doesn't allow it, it's the app's fault.
• [11:44] Which Linden: yeah
• [11:45] Which Linden: so, yes, definitely people are out there writing lazy apps, but ... what's new?
• [11:45] Morgaine Dinova: Nothing new, but one doesn't have to follow them :P
• [11:47] Morgaine Dinova: So what's the next topic?
• [11:47] Which Linden: well my next topic was gonna be, should dinosaurs be allowed to skateboard?
• [11:47] Which Linden: [2]
• [11:47] Which Linden: ^ illustration
• [11:47] Which Linden: that could really revolutionize things
• [11:48] Morgaine Dinova: You mean because they could skate away from the approaching (probably mythical) asteroid 65my ago? :-)
• [11:48] Which Linden: or skate over it, and the ensuing tsunami!
• [11:49] Morgaine Dinova: Hehe
• [11:49] Which Linden: doing the 360-million-year benihana
• [11:49] Which Linden: well, we only got about 10 minutes left
• [11:50] Morgaine Dinova: It's funny how ingrained the asteroid-wipes-out-dinosaurs thing has become, despite the extinction taking nearly a million years :-)
• [11:50] Which Linden: hmm... yes, well, um, it was precipitated by an aasteroid though right?
• [11:51] Morgaine Dinova: The phrase "contributory factor" is probably too much of a tongue twister.
• [11:51] Morgaine Dinova: Doesn't fit into sound bites :-)
• [11:52] Which Linden: ok, well, here's something of actual substance to talk about: http pipelining
• [11:52] Which Linden: it's a nice feature built in to http/1.1
• [11:52] Morgaine Dinova: You mean Ted Stevens was right after all? ;-)
• [11:52] Which Linden: basically, instead of request/wait/response
• [11:52] Which Linden: hah, yes, it's like a tube
• [11:52] Morgaine Dinova: chuckles
• [11:53] Which Linden: ......you send down a crapload of requests and then wait for the responses to come back in order
• [11:54] Morgaine Dinova: How much is a crapload in units of Libraries of Congress per furlong?
• [11:54] Morgaine Dinova: Don't answer :P
• [11:54] Which Linden: I think... there is some sort of limit
• [11:54] Which Linden: like the tcp window size
• [11:54] Morgaine Dinova: Aha
• [11:55] Which Linden: [3]
• [11:55] Which Linden: nope, no limit
• [11:56] Which Linden: so.... a poorly behaved client could queue up a lot of requests before getting a response, but a well-designed server will put the kibosh on that
• [11:56] Which Linden: or just, you know, serve the requests in the order received
• [11:57] Which Linden: it's not like clients can't send a storm of requests at a server without pipelining, so it's no new problem
• [11:57] Which Linden: so, that's useful!
• [11:57] Which Linden: the more you know!
• [11:59] Morgaine Dinova: Oh, the "no new problem" goes a lot further back than that. IP has always been able to queue up a zillion requests and then let them through all at once: eg. temporary block in a corporate firewall, thousands of GETs suddenly being let through.
• [11:59] Which Linden: yep
• [12:00] Which Linden: just gotta make your system tolerant to faults
• [12:00] Morgaine Dinova: Plus retransmit floods, the system stack has to be able to handle those, which they do fortunately.
• [12:00] Which Linden: well, looks like that's about it
• [12:01] Lalinda Lovell: bye
• [12:01] Which Linden: yes, being careful about idempotency is very important for handling retransmissions
• [12:01] Morgaine Dinova: Lunch time for you ;-)
• [12:01] Which Linden: time to eat some plant food
• [12:01] Morgaine Dinova: Hehehe
• [12:01] Which Linden: thanks so much, all!
• [12:01] Morgaine Dinova: Thanks Which, see you again :-)
• [12:01] Which Linden: catch you next time