User:Which Linden/Office Hours/2009 Jan 22

• [11:08] Which Linden: Hey there, so sorry to be late
• [11:08] TheBlack Box: Hi
• [11:08] Which Linden: Hi TheBlack
• [11:09] Which Linden: I got too comfrotable in a bean bag chair and ran over my allotted chillout time
• [11:10] TheBlack Box: np ... :) ... to we have a specific agenda for this office hour ?
• [11:11] Which Linden: Last time, we ended with Eddy asking about use cases for message queues
• [11:11] Which Linden: Were you there last time?
• [11:11] TheBlack Box: because i have an AWG-related topic that i would just want to shortly
• [11:11] TheBlack Box: no sorry
• [11:11] TheBlack Box: +mention
• [11:11] Which Linden: Well, what's your AWG-related topic? I should remind you that I'm not as invovled with that group as I wish to be
• [11:12] TheBlack Box: i tried to put it together here for comments: [1]
• [11:12] TheBlack Box: about hierachical linking
• [11:12] Which Linden: Oh, yes, we used to actually have that in the beta of second life
• [11:12] TheBlack Box: but not enough ppl understad the implications of it so i tried to make the jira-entry explanotory
• [11:13] Which Linden: Nice diagrams
• [11:13] TheBlack Box: thanks ;)
• [11:13] Which Linden: I believe that joints were removed because of stability problems
• [11:13] TheBlack Box: well .. i guess that all i wanted here already ... just to raise awareness
• [11:14] Which Linden: I wasn't here though, so I think I just read that on some blog somewhere on the internet
• [11:14] Which Linden: Ha ha ha, yes, we're in agreement that joins would be so awesome to have
• [11:15] TheBlack Box: yes ... i never saw the way they worked once ... but i think hierachical linking is important .. and if any prim thats an inner node of a tree-structure would be a joint ... i dont see much of a problem on the theoretical side
• [11:15] Which Linden: I'm not sure if it's necessary to conflate joints with hierarchical linking
• [11:16] Which Linden: Though I guess that's the natural way of thinking about it
• [11:16] TheBlack Box: it would be the clean solution i think ... and since current brokenness of roations cry for a LSL3 ... have you seen [2] ?
• [11:16] Morgaine Dinova: 'Morning :-)
• [11:17] TheBlack Box: read linden-comments of svc-93 ;)
• [11:17] Morgaine Dinova: Was out shopping, sorry late ;-)
• [11:17] TheBlack Box: hey :)
• [11:17] Which Linden: LOL at SVC-93
• [11:17] Which Linden: Hi Morgaine
• [11:17] Morgaine Dinova: Hiya Which :-)
• [11:17] Morgaine Dinova: reads back
• [11:18] TheBlack Box: hi :) ... so Which ... i am trying to bring up the idea that LSL3 plus clean hierachical linking would be nice .. and worth more than a thought
• [11:19] Morgaine Dinova: And I'm trying to raise awareness of hierarchical linking too, Which :-) -- https://wiki.secondlife.com/wiki/Prim_and_Object_Hierarchy
• [11:19] TheBlack Box: of cause: i am aware that current stability issues areand should be highe up on the priority-list ...
• [11:20] Which Linden: Hierarchical linking and LSL3 are separate concerns; but yes, if either gets some dev time that would be nice
• [11:20] Morgaine Dinova: Seeing as everyone and their dogs are shedding tech staff at this moment, I suggest that LL picks up another 100 or so ^_^
• [11:20] Which Linden: You should link that wiki page to MISC-2237
• [11:21] Which Linden: My pony is I'd like an LSL3 that doesn't have a flat namespace of LLFoo functions, but instead has, like, object-orientation
• [11:22] TheBlack Box: which: if you think about link-messages .. the problem that svc-93 cant be fixed in LSL2 without breaking existing content .... tree-oriented functions ....
• [11:23] Which Linden: Right, but one could imagine supporting hierarchical linksets without breaking the existing behavior
• [11:23] TheBlack Box: i think LSL3 and hierachical linking goes hand-in-hand ..... what about bvh for linked objects ? :)
• [11:23] Morgaine Dinova: I absolutely do not advocate making *current* prims hierarchical --- that would be a backwards compatibility disaster. But new prims should be introduced, like the old ones, but with hierarchical ability (ie. all are containers too).
• [11:23] Which Linden: Definitely hierarchical linking would be easier to implement if you could expose its script handles via LSL3
• [11:24] TheBlack Box: exactly ... approaching hirachical linking and LSL3 at once makes a lot of things easier and is a nice wall to protect existing content
• [11:26] Which Linden: Yeah, I guess I'm getting out of my depth here -- I don't really know a thing about lsl or the physics engine
• [11:27] TheBlack Box: tomorrow i will bring up the issue at qarls office hour ... i dont want to be annoying ... but i think this need some consideration in a really large context
• [11:28] Which Linden: That's a good idea. Qarl will have more insight than I
• [11:28] Morgaine Dinova: Black, I think "annoying" is pretty much part of the process ... suggestions from us lot are a big headache, hehe. Even if necessary ^_^
• [11:28] TheBlack Box: good :) but in general you think this is worth following up on right ?
• [11:29] Which Linden: I think that it would be useful to start cataloguing and describing the desired overall API that would be the end goal, adding on as incompatibilities with the existing APIs (such as SVC-93) are discovereed
• [11:29] Morgaine Dinova: Well there will be no real product engineering in SL until we have hierarchical object composition. We cannot build on the shoulders of others, currently.
• [11:30] Which Linden: You're probably not going to be able to imediately change the allocation of engineers within the company, but you can make it so that if/when we do, it's easier for those engineers to tackle it
• [11:30] TheBlack Box: yes makes sense ... there is also a big wish-list here which could be looked at for more ideas on LSL3: [3]
• [11:30] Which Linden: Wow, there's a lot there, innit
• [11:31] Morgaine Dinova: It's like trying to build a computer out of raw sand for silicon and rock for metal ore ... that's not the way to build computers ;-)
• [11:32] Which Linden: Yes, we're definitely in the 8050 era of LSL, if the analogy is computer processors
• [11:32] Which Linden: Maybe even as far down as ENIAC-level
• [11:34] Which Linden: So, um, Eddy doesn't seem to be online, are you all interested in the use cases for message queues?
• [11:34] Morgaine Dinova: Well at least people have built quite a lot of level-1 components. How we just need a way to compose them into higher-level objects. :-)
• [11:35] Morgaine Dinova: s/How/Now/
• [11:35] Morgaine Dinova: I'm definitely interested in message queues.
• [11:36] TheBlack Box:  :) ... ok ... honestly i am not ... i will head back to fixing my self-made problems now .. thanks a lot Which for listening ! :)
• [11:36] Which Linden: Thanks for stopping by, Black Box!
• [11:36] TheBlack Box: bye
• [11:36] Which Linden: cya!
• [11:37] Which Linden: OK then, just you an me
• [11:37] Which Linden: And all the readers of the transcript :-)
• [11:37] Morgaine Dinova: Tut tut @ Black, lol
• [11:37] Morgaine Dinova: Right, let's have it :P
• [11:37] Which Linden: Ha ha ha, he's honest, rather have that then silent bored attendance
• [11:38] Morgaine Dinova: I'll post a reminder in Groupies anyway
• [11:38] Which Linden: Yes, so, first use case and the most obvious is group chat
• [11:38] Which Linden: We discussed that last time
• [11:38] Which Linden: Person-to-person IM is also a use case (though that works OK for now so we have no reason to reimplement it)
• [11:39] Which Linden: The tricky bit about person-to-person IM is how to deal with IMs when offline
• [11:39] Which Linden: And also how to continue to cap the messages, as we do now
• [11:40] Which Linden: And before you say that the cap sucks; I know, but we have to have a cap of soe sort
• [11:40] Morgaine Dinova: Maybe worth mentioning what kind of comms is NOT a use case for message queues :P
• [11:41] Which Linden: Ha ha, well, editing your profile, for example, is not a use case
• [11:41] Which Linden: That's an obvious one
• [11:41] Which Linden: Another thing that I don't think is a use case for a message queue is derezzing to inventory
• [11:41] Morgaine Dinova: Caps don't suck, caps are part of resource control. It's only caps that are set below normal usage levels that suck :-))))
• [11:41] Which Linden: Fair enough :-)
• [11:42] Which Linden: Hi Lalinda
• [11:42] Lalinda Lovell: hi
• [11:42] Morgaine Dinova: Would it be fair to say that anything that requires the server end to have client-like access to the viewer is a use case?
• [11:42] Morgaine Dinova: Hiya Lal :-)
• [11:43] Lalinda Lovell: which do you know anything about the disaster that is merging grids?
• [11:43] Lalinda Lovell: i am really worried
• [11:43] Morgaine Dinova: Merging grids? Don't get that
• [11:43] Which Linden: Morgaine: I don't think the event queue is a use case, but that matches your criteria
• [11:43] Which Linden: Yeah no idea whatyou're talking about Lalinda
• [11:43] Lalinda Lovell: teen grid is now merged
• [11:43] Lalinda Lovell: with here
• [11:44] Which Linden: It is? I don't see anything like that on the blog....
• [11:44] Lalinda Lovell: its definite
• [11:45] Which Linden: Well I'm afraid I don't know anything about any such thing
• [11:45] Morgaine Dinova: Which: well that's why I was trying to define the use case spectrum better. If the event queue needs to be excluded, then I'm confused about how use cases are defined, because IM is a clear use case for event queues as well as message queues .. just depends how you define things.
• [11:45] Latif Khalifa: hi
• [11:45] Morgaine Dinova: Hiya Lat!
• [11:46] Which Linden: Good day!
• [11:46] Lalinda Lovell: [4]
• [11:46] Morgaine Dinova: Oh yeah, Philip said (for all intents and purposes) that the Teen and Main grid would merge.
• [11:46] Lalinda Lovell: i didnt think it would be so quick
• [11:46] Lalinda Lovell: you can see teen grid on the map now
• [11:46] Which Linden: Oh, ok. Well, do you ind continuing to discuss message queues, since that's somethiing I actually know soething about?
• [11:46] Latif Khalifa: haha
• [11:47] Lalinda Lovell: feel free
• [11:47] Which Linden: Morgaine: I may reconsider my opinion of the event queue
• [11:48] Morgaine Dinova: Well I think merging the two grids would just ensure that a lot of us wouldn't hang around SL much, there's only so many "sup bro"'s one can take ...
• [11:48] Which Linden: The way I was envisioning things, the event queue is itself a consumer of a bunch of message queues (such as your IM queue)
• [11:48] Morgaine Dinova: Some of the infantile adults are bad enough ;-)
• [11:49] Morgaine Dinova: Aha
• [11:49] Morgaine Dinova: OK, that might make sense ... /me thinks
• [11:50] Which Linden: So in that sense the event queue is a use case for message queues, in that many of the things that go in the event queue come fro message queues, but it, itself, is not an independent queue or accessed via that interface
• [11:51] Morgaine Dinova: Btw, if it's not restricted info, is the evaluation of alternative AMQP systems a short-term targetted Need Now! thing, or just a back-burner project? I didn't really get a feeling for that from Inifinity.
• [11:51] Morgaine Dinova: Which: I'd agree
• [11:53] Which Linden: Morgaine: both types of project, in that we'd like to have one decided sooner rather than later so we can start using whatever it is, but non-urgent because nothing is currently collapsing due to lack of such a tool
• [11:54] Morgaine Dinova: I was going to say that the relative slowness of the event queue to clients might mean that it could work layered on top of message queues ... but I'm not so sure really. Event queues are slow right now because of the polling, but they needn't be if done properly.
• [11:54] Morgaine Dinova: Aha
• [11:55] Morgaine Dinova: I never did figure out why Zero wants event queue traffic to be polled instead of streamed at max queue rate. There should be an event handler for each event type on the client anyway, why not let it work independently?
• [11:55] Lynyrd Lenroy: hello
• [11:56] Lynyrd Lenroy: have i walked into another meeting?
• [11:56] Lalinda Lovell: yes its a meeting
• [11:56] Morgaine Dinova: Yup, but it's an open meeting, if you're interested in the tech.
• [11:56] Lynyrd Lenroy: hmm, aint that bright
• [11:56] Which Linden: yes, my office hours, we're talking about essage queues
• [11:56] Lynyrd Lenroy: lol
• [11:56] Lynyrd Lenroy: couldnt even tell you what that was
• [11:56] Lynyrd Lenroy: this is my third day right
• [11:57] Lynyrd Lenroy: and the second meeting ive crashed
• [11:57] Which Linden: Morgaine: I thought that the event queue was a strea
• [11:57] Morgaine Dinova: Only bright people allowed, sorry. We're all IQ 1,000 here, except me, only 999 :-(
• [11:57] Latif Khalifa: lmao
• [11:57] Lynyrd Lenroy: ok, enjoy
• [11:57] Which Linden: You're certainly welcome to listen in
• [11:57] Morgaine Dinova: Awww :-)
• [11:57] Lynyrd Lenroy: i'll be quiet
• [11:58] Lynyrd Lenroy: lol
• [11:58] Which Linden: Some other esoteric use cases, just to get you thinking: during registration via the reg api, a reg api client could give inventory to the newly-registered user; it would be best if this inventory was not transferred in the middle of a web service request but instead a message was dropped into some queue that said "give this inventory item to this Resident"
• [11:58] Which Linden: ...and then an async process did the actual transfer
• [11:58] Lalinda Lovell: library inventory?
• [11:58] Morgaine Dinova: Which: it's a stream that only sends when requested by poll, unless I've totally misunderstood --- and I would be very happy to hear I've misunderstood! :-)
• [11:58] Which Linden: Lalinda, kinda
• [11:59] Which Linden: Morgaine: I think that the implementation of the event queue is intended to be as stream-like as possible, and if that's only achievable with a "long poll", then so be it, but it should be made as stream-like as possible
• [11:59] Morgaine Dinova: Which: that's a good use case. What you're saying is, concurrent updates are natural candidates for message queues.
• [11:59] Which Linden: E.g. ptth as an example of aking it more strea-like
• [12:00] Which Linden: Concurrent updates -- kinda
• [12:03] Which Linden: yeah, any time that you don't want to actually wait for something to finish, use a message queue
• [12:04] Which Linden: OK, looks like this conversation has died off a bit; I will try to dig up more use cases of interest.
• [12:04] Which Linden: Till next week, then!
• [12:04] Lalinda Lovell: bye
• [12:04] Lalinda Lovell:  :)
• [12:04] Morgaine Dinova: Cya Which, take care :-)
• [12:04] Which Linden: Thanks all for dropping by! Muchas smuchas!