User:Which Linden/Office Hours/2009 Jan 15

• [11:00] Saijanai Kuhn: wo what brings you to the bamboo Infinity?
• [11:00] Morgaine Dinova: 'Morning Which :-)
• [11:00] Infinity Linden: were i rezzed here, i would wave back at you Morgaine...
• [11:00] Which Linden: Good morning!
• [11:01] Shaun Altman: oh is this an office hour?
• [11:01] Infinity Linden: just listening
• [11:01] Saijanai Kuhn: which? Where?
• [11:01] Shaun Altman: hi Which
• [11:01] Catherine Pfeffer: Good evening everyone
• [11:01] Morgaine Dinova: chuckles
• [11:01] Which Linden: Hi Infinity, glad to have you here
• [11:01] Morgaine Dinova: Hiya Catherine
• [11:01] Infinity Linden: oh oh... i'm not officially here
• [11:01] Tree Kyomoon: hideeho!
• [11:01] Which Linden: Oh, glad to have you .... not here
• [11:01] Catherine Pfeffer: Hi Morgaine ;-)
• [11:01] Infinity Linden: just listening
• [11:01] Gonta Maltz: I am not here, I did not say these things.
• [11:01] Which Linden: This is a bigger crowd than usual. Is there an occasion?
• [11:02] Morgaine Dinova: I've not heard any Infinity here, what are you folks on about? ^_^
• [11:02] Infinity Linden: sai evoked the spam cap
• [11:02] Gonta Maltz: yes, you're announcing that big thing
• [11:02] Tree Kyomoon: Listen Linden!
• [11:02] Shaun Altman: I just kinda randomly stumbled on a bunch of green dots.
• [11:02] Shaun Altman: lol
• [11:02] Ciemaar Flintoff: I think it just got announced at the right time
• [11:02] Saijanai Kuhn: wjat boig tjomg
• [11:02] Saijanai Kuhn: er, what big thing?
• [11:02] Which Linden: Ha ha ha, "you're bored, so come on over here!"
• [11:02] Morgaine Dinova: Yes Shaun, it's a tech office hours, and please switch off your rocket engine noise.
• [11:02] Shaun Altman: oh sorry
• [11:02] Morgaine Dinova: Thanks
• [11:03] Shaun Altman: I don't have my headset on heh
• [11:03] Infinity Linden: oh.. you know.. the secret big thing...
• [11:03] Saijanai Kuhn: oh that one
• [11:03] Ciemaar Flintoff: hmm, are these using SL Voice? 'cause I never got that working
• [11:03] Which Linden: Right, well, since it's secret we won't be announcing it
• [11:03] Infinity Linden: so secret we didn't tell ourselves about it
• [11:03] Morgaine Dinova: lol
• [11:03] Gonta Maltz: Personally I just wanted to attend more meetings, and get a rounder view
• [11:03] Saijanai Kuhn: Been there done that. SO secret, that if I told you, I would have to kill... me
• [11:04] Morgaine Dinova: Does "end of month" actually have a date, for the announcement?
• [11:04] Tree Kyomoon: Im here for the pickles. Wait, where are the pickles?
• [11:04] Which Linden: Is there an actual secret announcement? I was just horsing around.
• [11:04] Gonta Maltz: I just made it up!
• [11:04] Infinity Linden: hmm... i think gonta should file a PJIRA
• [11:04] Omegadon Aeon: Why is Which a plant?
• [11:04] Which Linden: OK, that's what I thought!
• [11:04] Nathiel Siamendes: Hello
• [11:04] Infinity Linden: to get us to announce our secret thing
• [11:05] Which Linden: Well, if you all are interested in a technical topic, we can discuss the message queuing systems that we've been evaluating
• [11:05] Morgaine Dinova: Yeah there is one at end of month, and also a pre-leak. But we're waiting for the official one, "end of month".
• [11:05] Morgaine Dinova: Cool, Which!
• [11:05] Saijanai Kuhn: still wanting to see the pre-leak
• [11:05] Which Linden: I've been hammering on RabbitMQ lately, it's pretty nice
• [11:06] Tree Kyomoon: is that chat message or server/client message?
• [11:06] Which Linden: How familiar are you all with message queuing software? Server-only, Tree.
• [11:06] Which Linden: Perhaps I shold explain the general concept here
• [11:07] Morgaine Dinova: Not familiar at all here except from reading Wikipedia, so details would be nice.
• [11:07] Which Linden: I can explain the AMQ model, because it's pretty well-formed and reasonable, and you cna probably match other systems up to it roughly
• [11:08] Which Linden: From a message consumer's perspective, you connect to a server, and send along a list of queues that you wish to subscribe to
• [11:08] Which Linden: This subscription request is idempotent; meaning if the queue doesn't exist it creates one
• [11:08] Which Linden: The queue has two parts: a name, and a key
• [11:09] Tree Kyomoon: in xml or?
• [11:09] Which Linden: The name is pretty much for disambiguation, the key is for routing
• [11:09] Which Linden: Um, format unspecified, Tree. AMQP has a binary protocol, but it's not importatn
• [11:09] Which Linden: When you subscribe to the queue, you then start getting notifications about messages that are delviered to the queue
• [11:09] Morgaine Dinova: Hiya Latif
• [11:10] Latif Khalifa: hi :)
• [11:10] Which Linden: This means that every message consumer maintains an active TCP connection to the server
• [11:10] Saijanai Kuhn: I can see where ptth would come in handy there
• [11:10] Morgaine Dinova: So far that's exactly like the plugin system we're developing for Imprudence :-)))
• [11:10] Catherine Pfeffer: for each queue ? the active tcp cnx
• [11:11] Which Linden: AMQP has provisions to multiplex multiple queue subscriptions over one TCP connection
• [11:11] Catherine Pfeffer: ok thx
• [11:11] Latif Khalifa: active TCP connections from 20k simulators is kind of difficult to maintain :P
• [11:11] Which Linden: Though, yeah, if you were using ptth there would be one connection per queue
• [11:11] Tree Kyomoon: what if the 5672 port isnt available, does it tunnel?
• [11:12] Which Linden: I don't know about port 5762, Tree
• [11:12] Which Linden: The main responsibility the client has is to ack messages.
• [11:13] Tree Kyomoon: (looking at rabbitMQ.com ... this reminds me a bit of AMF"
• [11:13] Which Linden: "Main" meaning apart from the application logic that does stuff based on the essages
• [11:14] Infinity Linden: @Tree.. and MQSeries and Tibco, IMHO
• [11:14] Which Linden: If you want your architecture to be exactly-once delivery, then you have to be sure that the ack of the message is done atomically with whatever your application does based on the essage
• [11:14] Which Linden: People who are familiar with my CHTTP discussions from last year will start to get a familiar feeling..... :-)
• [11:14] Morgaine Dinova: points to the diagram above Which's head
• [11:15] Tree Kyomoon: is CHTTP still happening or?
• [11:15] Which Linden: There's a buncha ways that you can do the acking of the messages in an exactly-once way. I think some things support XA, and you could totally use the CHTTP worklog object to do the sae thing
• [11:15] Which Linden: Well CHTTP is in a queue behind some other technical work
• [11:16] Which Linden: But, OK, not every message has to be exactly-once
• [11:16] Tree Kyomoon: nice rabbit MQ faqs here: [1]
• [11:16] Which Linden: And that's fine, you can even configure things so that you auto-ack; which means that the server acks the messages when it thinks it's delivered them
• [11:16] Which Linden: So that's the client side
• [11:17] Which Linden: The sending side is even simpler.
• [11:17] Which Linden: When you want to send a message, you connect to the server, and then "publish" a message.
• [11:17] Which Linden: When you publish a message you include a body, and a routing key
• [11:18] Which Linden: This key corresponds in some way to the routing keys specified by the clients
• [11:18] Morgaine Dinova: Better define routing key, and its relationship to paths.
• [11:18] Tree Kyomoon: in what ways is this better than TCP?
• [11:18] Which Linden: So if a client sets up a queue bound to the routing key "foo" and the sender sends to routing key "foo', that client receives the essage
• [11:19] Saijanai Kuhn: osm
• [11:19] Which Linden: It's not point-to-point, and many clients can set up as many queues connected to the same routing key as they want
• [11:19] Morgaine Dinova: Define routing key please.
• [11:19] Saijanai Kuhn: wouldn't this sit on top of something like TCP?
• [11:19] Which Linden: Sai: yeah, it sits on top of TCP
• [11:19] Ciemaar Flintoff: I would expect they'll be sending these messages over TCP or UDP, message queues are a higher level contruct than TCP
• [11:19] Which Linden: Morgaine: it's just a string
• [11:20] Morgaine Dinova: Semantic?
• [11:20] Tree Kyomoon: it seems like unnecessary overhead then?
• [11:20] Which Linden: Morgaine: in a direct exchange (which is what we're talking about), there's no semantics to the routing key, it's just equality
• [11:20] Ciemaar Flintoff: what I missed is which messages are being carried here? IMs, state changes, commands?
• [11:21] Morgaine Dinova: Tree: it's raising the level of abstraction. Can't expect all endpoints to do everything at the low comms level.
• [11:21] Which Linden: Ciemarr: that's also unspecified. It could be any of those!
• [11:21] Ciemaar Flintoff: Tree, if it's formalized as a queue clients can catch-up and other useful operations
• [11:21] Tree Kyomoon: i thought XML did that pretty good meself
• [11:21] Morgaine Dinova: Which: aha, so it's a tag, and clients express interest in the tag.
• [11:21] Saijanai Kuhn: XML doesn't register client server relationships
• [11:22] Morgaine Dinova: Tree: XML is just serialization.
• [11:22] Morgaine Dinova: In this context anyway.
• [11:22] Which Linden: An "exchange" is basically the ruleset you use for delivering messages. I left this out when I was explaining the basic concept, but it can be important
• [11:22] Which Linden: The direct exchange is like we talked about, direct equality comparison on the routing key
• [11:23] Tree Kyomoon: so the exchange has to reroute/redistribute all the messages to support the attraction to the key?
• [11:23] Which Linden: Tree: yep
• [11:23] Tree Kyomoon: imagines yet another middle man between me and my SL fun
• [11:23] Which Linden: So it's pretty nice, to send a message you open up one tcp connection; to receive nearly any nuber of messages, another tcp stream
• [11:24] Ciemaar Flintoff: not another middleman, a replacement middle man, consider group IMs, rather than going through the poor group server, they would go through a queue
• [11:24] Which Linden: The details of how messages get routed aren't hard-coded into the system like it is currently; it's defined by the dynamic configuration of senders and receivers
• [11:25] Tree Kyomoon: so right now we open up a distinct TCP connection for every message, and this would allow us to send /recieve multiple messages on one TCP connection?
• [11:25] Morgaine Dinova: The routing key for event traffic effectively becomes a "conference" for IM traffic in XMPP parlance. Not exact analogy, but somewhat.
• [11:25] Which Linden: I believe the advantage is ostly in the abstraction, the conservation of tcp connections is nice though
• [11:25] Which Linden: My m key isn't working so well
• [11:25] Evita Tammas: boring
• [11:26] Tree Kyomoon: well being on satellight...the less tcp connections the better
• [11:26] Morgaine Dinova: Yes, the conservation of TCP connections is very important for scaling.
• [11:26] Eddy Stryker: i'm late to the party... are we talking about AMQP?
• [11:26] Which Linden: Eddy yeah
• [11:26] Tree Kyomoon: my electrons have to travel 30,000k for every one of them
• [11:26] Eddy Stryker: great
• [11:26] Ciemaar Flintoff: so, which is it pre-mature to consider queue overflows?
• [11:26] Which Linden: Ciemaar: not at all
• [11:26] Morgaine Dinova: Hiya Eddy. Yeah, Which is giving nice intro.
• [11:27] Which Linden: The behavior when there's no client, or when the client isn't acking messages fast enough, is a big point of difference between implementations
• [11:27] Eddy Stryker: any suggestions on which implementation is the most robust? there are too many to choose from... apache has activemq, then there's rabbitmq, etc
• [11:27] Which Linden: If you have a completely in-memory queue, what does the queue software do when you start to exceed available memory?
• [11:27] Which Linden: Eddy: we're evaluating that now
• [11:27] Morgaine Dinova: Just describing it atm, not comparing implementations.
• [11:27] Which Linden: No answer yet
• [11:28] Tree Kyomoon: or take too long between messages...a la timout?
• [11:28] Which Linden: Tree: that's acking too slowly, I think
• [11:28] Tree Kyomoon: I hope this doesnt make us 6000ms and longer folks become unable to use SL
• [11:28] Which Linden: Basically, in case of overflow the router can do two things: start killing messages, or stop receiving them
• [11:29] Which Linden: Or I guess it can overflow from memory onto disk, but that's just postponing the problem
• [11:29] Catherine Pfeffer: reminds me of current group ims ;-=
• [11:29] Morgaine Dinova: Architecturally it's identical, Catherine
• [11:30] Which Linden: I guess what behavior you want is application-dependent
• [11:30] Tree Kyomoon: waves at eddy
• [11:30] Which Linden: There's also the notion of whether queues persist when clients aren't listening
• [11:31] Which Linden: You can declare queues that die off when there's no client actively consuming them
• [11:31] Which Linden: And you can have ones that remain (I still haven't quite figured out how you're supposed to garbage collect these)
• [11:31] Tree Kyomoon: what time frame are we talking in this...4-5000ms or 30 seconds...minutes...?
• [11:31] Which Linden: Tree: for what? Message delivery is supposed to be nearly instantaneous
• [11:32] Eddy Stryker: hi tree
• [11:32] Tree Kyomoon: right but the range, IE before timeouts/garbage collection takes place
• [11:32] Which Linden: Oh....well that depends on the server hardware and configuration
• [11:32] Tree Kyomoon: internet is not instant for all of us :)
• [11:32] Ciemaar Flintoff: Which, a long term queue would let you crash and reconnect without losing your subscription
• [11:32] Morgaine Dinova: Since Which said that they're evaluating alternative implementations of AMQP, and Zero has said that XMPP is a bad semantic fit for SL's IM ... I'm wondering if LL are planning to use AMQP not only for server message transport but also for IM infrastructure. :-)
• [11:33] Tree Kyomoon: intelligent queue handling is what im getting at
• [11:33] Ciemaar Flintoff: that would be nice for many of the actions
• [11:33] Which Linden: Ciemaar: yeah, well, it depends on how uch that subscription is worth -- remember that a queue is just a pattern match
• [11:33] Eddy Stryker: Tree: you can setup an AMQP queue server however you like
• [11:33] Which Linden: So if you do care about receiving every single message that matches the pattern, then you want a durable queue
• [11:34] Infinity Linden: @Morgaine. as which said, we're evaluating a lot of different technologies, but we've definitely noticed that conceptually, GroupIM and abstract message queues are a good fit
• [11:34] Tree Kyomoon: im just trying to push which to set it up considering longer messaging then I guess.
• [11:34] Which Linden: If, when you crash, you don't care about the messages that flew by while offline, then you use a non-durable queue
• [11:34] Eddy Stryker: you can even do a store-and-forward queue, where it writes messages to disk and stores them until someone comes asking for it
• [11:34] Morgaine Dinova: Infi: yeah, not surprised.
• [11:34] Which Linden: Yeah, we're definitely evaluating this in the context of current group chat
• [11:35] Which Linden: The main challenge appears to be that it ought to perform reasonably even for multi-thousand-member groups
• [11:35] Morgaine Dinova: Any links to scalability info on Rabbit? Or any other?
• [11:35] Infinity Linden: but it's premaure to announce we're planning on using any particular implementation
• [11:35] Which Linden: Morgaine: I'm not sure I have a handle on Rabbit's scalability
• [11:35] Tree Kyomoon: feels like the slow kid in gym class who comes last...and everyones left already. (messages timeout)
• [11:35] Eddy Stryker: [2]
• [11:36] Morgaine Dinova: Infi: aye, evaluation != implementation :-)))
• [11:36] Eddy Stryker: rabbit sits on top of OTP, which is fairly proven technology
• [11:36] Ciemaar Flintoff: the other thing to consider is that if you lose a queue you could catch up through a different mechanism, like if you lost a queue of updates on an object you would just need to ask the sim for full details
• [11:36] Which Linden: It can do clustering, but any individual queue lives on only one host, so if that host goes down, you lose everything on it
• [11:36] Which Linden: Ciemaar: yeah, but, that's less than ideal because you ideally want your message senders to be able to fire-and-forget
• [11:36] Tree Kyomoon: but a queue contains a whole session or just a few messages?
• [11:37] Infinity Linden: good question. tibco and MQSeries were able to scale quite nicely. so while i don't have detailed info on RabbitMQ myself, i know it's conceptually similar. But yeah... getting real numbers would useful
• [11:37] Which Linden: Tree: not sure what you mean by "whole session", but, I think, no. It only contains unacked messages, i.e. messages that you have not seen yet
• [11:38] Tree Kyomoon: that makes sense...sorry for asking the dumb questions
• [11:38] Morgaine Dinova: OTP is very robust, like all of Erlang. And remember that even those XMPP trials that hit 1 million clients were done with ejabberd, which is an Erlang application. So Rabbit does seem to be betting on a good horse in this.
• [11:38] Which Linden: No, no, please continue asking questions that you think are dumb but are actually insightful
• [11:39] Which Linden: We're also going to evaluate QPID and ActiveMQ, both of which are pretty mature. ActiveMQ has the advantage of supporting hot failover
• [11:39] Which Linden: kinda
• [11:39] Ciemaar Flintoff: are there really many cases in SL where a message can be fired and forgotten? IM's maybe, though even those are logged somewhat, any world update is persisted by the sim and physics engine right?
• [11:39] Tree Kyomoon: plus its free in the gratis AND libre sense. I like my free to be in both senses.
• [11:39] Which Linden: Ciemaar: I don't think we'd send object updates via message queues
• [11:39] Which Linden: The semantics of object updates don't mesh well
• [11:40] Eddy Stryker: ciemaar: i think the idea is that the point of origin for a transaction or message should be able to fire and forget and move on with other tasks, and the messaging layer should worry about the dirty details of ensuring delivery
• [11:40] Which Linden: But yeah, IMs can be fired and forgotten (by the sender), actually quite a lot of things can be
• [11:41] Which Linden: E.g. presence notifications. Pretty much any blue box that shows up in your viewer is a good match for this stuff
• [11:41] Morgaine Dinova: Using Rabbit or any Erlang/OTP mechanism would give you something you've never had in SL: the ability for remote idle machines to assist those that are in need of power --- the central non-scalability of SL sims. So that does sound like an excellent way to go.
• [11:41] Ciemaar Flintoff: right Eddy, but when a presence notification is fired a client that's out of sync can just ask the same server that they ask on login who's online
• [11:42] Ciemaar Flintoff: that would be another client of the queue of course
• [11:42] Tree Kyomoon: sometimes you cant move on unless you know the response though
• [11:42] Tree Kyomoon: in fact, a lot of times you cant...and shouldnt
• [11:42] Which Linden: Hm, I see what you're getting at Ciemaar. What you're talking about is sort of the distinction between a blog and an RSS feed.
• [11:42] Infinity Linden: yes and no morgaine... to get the ultimate benefit we would have to rewrite a lot of our code in Erlang; something i don't think we're planning on this decade
• [11:43] Which Linden: One provides content, and you can fetch that to get the whole enchilada, and the other provides a steady stream of updates
• [11:43] Eddy Stryker: this decade is almost over though ;)
• [11:43] Ciemaar Flintoff: that's a good example yeah, if you lose track of the RSS feed(the queue) you just fall back to the blog archive, it seems to me like most of SL could follow that model
• [11:43] Morgaine Dinova: Infi: just the sim code :-)
• [11:43] Tree Kyomoon: cant imagine the headache of writing web apps that dont get to daisy chain all their requests....
• [11:43] Infinity Linden: but feel free to start the rumor we've got it planned for release in 2019. ;-)
• [11:44] Which Linden: Ciemaar: that's one use case, the other use case is the case where the message is the content
• [11:44] Morgaine Dinova: You mean 9 years after Opensim has done it? ;-)
• [11:45] Which Linden: Opensim is written in erlang?
• [11:45] Morgaine Dinova: Hehe, we're just jesting with Infi :-)
• [11:45] Latif Khalifa: knock on wood... noo
• [11:45] Which Linden: Heh, ok :-)
• [11:46] Morgaine Dinova: But the next sane grid will of course be written in Erlang ... I could pretty much place a bet on that ... because I would get involved too, since I like Erlang a lot :-)
• [11:46] Which Linden: No matter what technology we choose, there will likely be some element of partitioning that we'll have to implement ourselves
• [11:47] Which Linden: Rabbit has the most seamless clustering, but even then you have to pick a particular host to store your queues on
• [11:47] Latif Khalifa: yeah, and LL is going to outsource the server code, hell experiences ice age... :P
• [11:47] Latif Khalifa: opensource*
• [11:47] Morgaine Dinova: What's being opensourced?
• [11:47] Morgaine Dinova: reads back
• [11:48] Tree Kyomoon: the server code already is opensourced isnt it?
• [11:48] Latif Khalifa: jk... about the next grid being written in erlang
• [11:48] Eddy Stryker: tree: if you pay 250k
• [11:48] Latif Khalifa: Tree, despite saying "soon" more than a year ago, no its not :)
• [11:48] Which Linden: I think the biggest benefit to group chat will be simply switching from a push model to a pull
• [11:49] Morgaine Dinova: Oh, I didn't mean LL's grid. I said the next sane grid. 1) SL, 2) Opensim, 3) ScalableSim :-)
• [11:49] Which Linden: OK, I guess we're all done with message queues?
• [11:49] Tree Kyomoon: so the openlife guys paid 250K?
• [11:49] Tree Kyomoon: eeek
• [11:49] Eddy Stryker: which: what's the timeline on this research?
• [11:49] Eddy Stryker: do you plan on publishing any of your findings?
• [11:49] Eddy Stryker: tree: openlife is a bad hack of opensim
• [11:50] Which Linden: Eddy: we hope to have a preliminary result within weeks, and I'd like to be as transparent as possible but am not comitting to anything yet. :-)
• [11:50] Eddy Stryker: sure
• [11:50] Tree Kyomoon: and opensim is a hack of SL?
• [11:50] Tree Kyomoon: a lot of hacking....I need a cough drop
• [11:51] Latif Khalifa: Tree, opensim is independet from the scratch implemenatation of simulator written in c#
• [11:51] Morgaine Dinova: Eddy, is anyone in Opensim and Erlang fan? Might be prospects for an offshoot there.
• [11:51] Morgaine Dinova: an*
• [11:51] Which Linden: There's about a dozen essage queue systems out there, we're trying to evaluate as many of the as possible but as you can imagine we can only in-depth look at a handful
• [11:51] Saijanai Kuhn: there being a difference between being a hack and being a hack OF
• [11:51] Tree Kyomoon: "from the scratch"...a chestnut of a maleprop and point taken!
• [11:51] Eddy Stryker: if you happen to find a random intern sitting around though, consider tasking them with writing a white paper :)
• [11:52] Eddy Stryker: morgaine: talk to otakup0pe Neuman(n?)
• [11:52] Morgaine Dinova: kk
• [11:53] Caroline Walmer: wanna buy a helicopter? 1$
• [11:53] Latif Khalifa: lol
• [11:53] Tree Kyomoon: is that a hack of an opensim helecopter?
• [11:53] Eddy Stryker: yes
• [11:53] Eddy Stryker: where do i sign up for a helicopter
• [11:53] Caroline Walmer: helicopter
• [11:53] Caroline Walmer: 1$
• [11:53] Caroline Walmer: who
• [11:53] X-Flight Device: - Wear or Attach to Fly ANYWHERE: All Go
• [11:54] Caroline Walmer: where r u?
• [11:54] Tree Kyomoon: Ill take 10!
• [11:54] Eddy Stryker: sitting down, i'm a ninja named #1 Eddy
• [11:54] Caroline Walmer: wheres eddy?
• [11:54] Saijanai Kuhn: at least you're not talking to Which
• [11:54] Caroline Walmer: did you pay me?
• [11:54] Latif Khalifa: man, latest 1.22 build has some weird camera movement
• [11:54] Caroline Walmer: #1 eddy?
• [11:54] Which Linden: Ha ha ha, see now, in HiPiHi, the helicopter is just in the right-click menu
• [11:54] Eddy Stryker: yes
• [11:55] Eddy Stryker: really which?
• [11:55] Tree Kyomoon: I paid you 10 lindens
• [11:55] Morgaine Dinova: Don't get helicopter salepersons confused, they might forget to put the rotor in the box.
• [11:55] Which Linden: Eddy: last tie I saw, which was a year ago. It was hilarious
• [11:55] Eddy Stryker: we need a jira for pie menu helicopter
• [11:55] Which Linden: SRSLY
• [11:55] Caroline Walmer: who gave me 1$?
• [11:55] Eddy Stryker: i did
• [11:55] Caroline Walmer: where r u?
• [11:55] Caroline Walmer: omfg
• [11:55] Which Linden: I'd suggest pie-menu Tyrannasaurus though
• [11:55] Caroline Walmer: where?
• [11:55] Caroline Walmer: oh
• [11:55] Tree Kyomoon: youd think there would be helecopter pie in SL. We can do anything here.
• [11:55] Caroline Walmer: you
• [11:56] Caroline Walmer: you need to drag it where you are allowed
• [11:56] Caroline Walmer: it doesne't work here
• [11:56] Which Linden: Oh yeah I have some restrictive land perms here
• [11:56] Saijanai Kuhn: realizes that particle effects aren't affected by wind. Would be a nice option in some cases...
• [11:56] Caroline Walmer: they look like this
• [11:56] Latif Khalifa: there is such option
• [11:56] Caroline Walmer: you can fly it
• [11:57] Morgaine Dinova: Which only allows bamboo seeds to rez
• [11:57] Caroline Walmer: but i'm wearing to show you
• [11:57] Caroline Walmer: wanna buy a helicopter? 1$
• [11:57] Which Linden: Ah, the loopholes in our permissions system
• [11:57] Ciemaar Flintoff: are we going to take up another topic?
• [11:57] Caroline Walmer: wanna buy a helicopter? 2$
• [11:57] Caroline Walmer: wanna buy a helicopter? 2$
• [11:57] Caroline Walmer: wanna buy a helicopter? 2$
• [11:57] Which Linden: Hey no spamming Caroline
• [11:57] Latif Khalifa: Caroline is working hard for her lindens :P
• [11:57] Tree Kyomoon: I gave you 10 lindens for 10 helecopters...now the price is 2$?
• [11:58] Caroline Walmer: huh?
• [11:58] Which Linden: I guess my office hours are over
• [11:58] Caroline Walmer: 1$
• [11:58] Caroline Walmer: then
• [11:58] Caroline Walmer: oh
• [11:58] Caroline Walmer: sorry
• [11:58] Saijanai Kuhn: sighs
• [11:58] Caroline Walmer: i didn't see you
• [11:58] Which Linden: I'll catch some subset of you all next week. :-)
• [11:58] Caroline Walmer: oh
• [11:58] Caroline Walmer: i'm so sorry
• [11:58] Ciemaar Flintoff: kk, take care
• [11:58] Tree Kyomoon: /bamboo isnt very assertive...perhaps a cactus?
• [11:58] Eddy Stryker: which: what else are you considering queueing protocols for? aside from IMs
• [11:58] Which Linden: It's OK, they were pretty much over anyhow
• [11:58] Saijanai Kuhn: nice talk which
• [11:58] Caroline Walmer: where r u tree kymoon
• [11:58] Morgaine Dinova: You might consider running Office Hours in a spot less close to newbie land ;-)
• [11:58] Which Linden: Eddy: I am still trying to figure that out
• [11:58] Tree Kyomoon: thanks which, I enjoyed it!
• [11:59] Tree Kyomoon: Im a skeleton!
• [11:59] Saijanai Kuhn: He's the skeleton next to da bum
• [11:59] Morgaine Dinova: Thanks Which :-)
• [11:59] Which Linden: Will try to discuss use cases next time.
• [11:59] Eddy Stryker: k
• [11:59] Which Linden:  :-)
• [11:59] Caroline Walmer: who paid me?
• [11:59] Caroline Walmer: stand up
• [11:59] Which Linden: Enjoy yourselves!
• [11:59] Caroline Walmer: duh?