User:Zero Linden/Office Hours/2008 Mar 20

[8:33] Zero Linden: hello all
[8:33] Larissa Vacano: Hello
[8:33] Morgaine Dinova: 'Morning Zero
[8:33] Yeesha Voom: hello
[8:33] Morgaine Dinova: Attendance numbers sure vary a lot :-)
[8:33] Harleen Gretzky: Hello Zero
[8:35] Zero Linden: I'm running to get a cup of.... coffee!!! back in a minute.
[8:35] Ninja Flight: Feather 1.2.1: secondlife://Grasmere/178/118/27
[8:36] Zero Linden: back
[8:37] Morgaine Dinova: Wb :-)
[8:37] Morgaine Dinova: Zero, would it be possible to talk about scalability today?
[8:37] Larissa Vacano: welcome back
[8:37] Tao Takashi: Hi
[8:37] Zero Linden: Sure - though I wanted to also dive in on the related question about other transports
[8:38] Zero Linden: I did some research on XMPP and AQMP
[8:38] Anders Falworth: Hi, all.
[8:38] Zero Linden: AMQP?
[8:38] Larissa Vacano: Hello
[8:38] Zero Linden: let's give folks another two minues
[8:38] Morgaine Dinova: Transports would be fine too. I'm just concerned that nobody seems interested in one of the two main pillars of the project :-)
[8:38] Tao Takashi: that's where marketing comes in again ;-)
[8:39] Tao Takashi: great how my mac migration says everything from it takes 20 mins to 19 hrs
[8:40] Tao Takashi: now it went up again from 20 mins to 1:50
[8:40] Morgaine Dinova: Tao, got my message about your .flv files? It seems impossible to play them offline.
[8:40] Zero Linden: hey - at least it tries to reestimate...
[8:41] Tao Takashi: Morgaine: yes. But I doubt I can do anything about it
[8:41] Zero Linden: true enough
[8:41] Zero Linden: OKAY
[8:41] Tao Takashi: I'd suggest to use the mp3 for listening to it
[8:41] Morgaine Dinova: Tao: you didn't encode them yourself?
[8:41] Zero Linden: Welcome to my office hours -
[8:41] Tao Takashi: no, that's ustream doing for me
[8:41] Tao Takashi: and I guess it's mainly intended for watching it at your computer (and probably live)
[8:41] Zero Linden: As you probably know - these discussions are transcribed into the wiki
[8:41] Morgaine Dinova: Well tell ustream to use something standard for audio :-)
[8:41] Zero Linden: for all time - so speak freely and speak openly
[8:42] Zero Linden: We had a greate AWG2 meeting - at least from my perspective
[8:42] Tao Takashi: I guess in this case the video is rather boring anyway ;-)
[8:42] Movies1963 Beck: Zero when Google steps in will AW still be listened to or are they going to "try things" their way first?
[8:42] Tao Takashi: from my, too :)
[8:42] Zero Linden: a bit long perhaps, but good none-the-les
[8:42] Tao Takashi: and too short ;-)
[8:42] Zero Linden: I don't seem to have a mole at Google - so I don't know what, if anything, they are thinking! :-)
[8:42] Morgaine Dinova: Zero: what were the salient points of AWG2 for you?
[8:43] Movies1963 Beck: you might not have a mole Zero but transitioning takes time
[8:43] Movies1963 Beck: this didnt happen overnight
[8:44] Morgaine Dinova: Zero: well now that you mention Google, there is no way in hell they are going to stay away from the search and advertising space in VWs ... you you really need some plan for when they do whatever they do :-)
[8:44] Zero Linden: I'm just saying, I can't predict a future with Google....
[8:44] Movies1963 Beck: there's nothing to predict
[8:45] Morgaine Dinova: Predicting isn't any help. You need to make it happen by going to them.
[8:45] Movies1963 Beck: or do you mean you can't predict if AW will be listened to by Google?
[8:45] Tao Takashi: the question is mainly: will there be an API for getting object data out of a region/agent domain or will it be bots looking around like they work now on the web
[8:45] Zero Linden: So, I'm going to leave Google out of our discussion - you can be sure that LL talks about Google internally for business reasons, but I don't yet see a substative way in which thinking about Google affects the AWG's current work
[8:45] Morgaine Dinova: Zero: Google knows how to scale. LL currently doesn't
[8:45] Zero Linden: Tao - I'm not sure it makes much difference, eh? The API would be cleaner and less resource drain, the bots have positive and negative social consequences
[8:46] Morgaine Dinova: I missed out the word "demonstrably", in reference to scaling
[8:46] Tao Takashi: well, I'd go for an API if possible
[8:46] Tao Takashi: also to give more people the same chance of making a good search. running bots sounds more like a hack to me
[8:46] Zero Linden: Morgaine - on technical fronts I have consumed every scaling paper Google has produced (okay, not every, but a lot of 'em)
[8:46] Zero Linden: and it is clear they know how to scale a very different problem
[8:47] Zero Linden: many of their assumptions dont' hold here
[8:47] Zero Linden: and so much of the work isn't applicable
[8:47] Tao Takashi: like denormalize everything..
[8:47] Zero Linden: BUT - back to the question about takeways from AWG2
[8:47] Movies1963 Beck: I wasnt talking about Google taking over the search, I ment when Google take control of SL
[8:47] Zero Linden: 1) We basically agree on form and logistics and phases, with some tweaking of the original list I drew up
[8:48] Morgaine Dinova: Agreed the problem spaces aren't identical. However, within SL-NG there will be a search and advertising scalability aspects. In that, Google's experience will be directly applicable to the scalability requirement.
[8:48] Zero Linden: 2) Threre are several implemetnation efforts underway
[8:48] Tao Takashi: I summarized your points here a bit: [1]
[8:48] Tao Takashi: (there is also audio and video)
[8:48] Zero Linden: 3) There were three big questions
[8:49] Zero Linden: Should we consider an alternative to the event queue for region/agent to viewer communication
[8:49] Zero Linden: How will we handle variety of data formats (prims, avatars, etc...)
[8:49] Morgaine Dinova: I'm interested in that question --- you may have seen my input to your protocol doc on the wiki
[8:49] Morgaine Dinova: event queues I mean
[8:49] Zero Linden: How much is part of the required spec, and how much are additional specs.
[8:50] Zero Linden: I'd like to talke about the first one too, since I did some investigation since Tuesday
[8:51] Zero Linden: So -
[8:51] Morgaine Dinova: Perhaps we could dedicate some time now to it?
[8:52] Zero Linden: We have four ideas on the table for how to communicate back to the viewer
[8:52] Zero Linden: 1) Event Queus, 2) XMPP, 3) AMQP, 4) Some custom protocol built on TCP
[8:53] Zero Linden: Adam indicated that for #4 he proposed running the current binary message format that is in UDP, but over TCP
[8:53] Tao Takashi: I think he said, the implementation should decide
[8:53] Zero Linden: Now, I can speak to the two middle ones, and why I think they are likely unsuitable
[8:54] Tao Takashi: does it have any advantage to run this over TCP vs. having a different format over TCP?
[8:54] Morgaine Dinova: Well #4 is a catchall, and #1 is actually part of #4 since our implementation of event queues is most definitely not that of COMET.
[8:54] Zero Linden: Tao - meaning we woudln't spec it? How would anything interoperate
[8:54] Tao Takashi: no idea ;-)
[8:54] Tao Takashi: but I think he said something like that
[8:54] Tao Takashi: but I think it will lead to more problems on the interop front
[8:54] Zero Linden: Well, #1, the Event Queus are built on HTTP, and that is an important aspect of them
[8:55] Zero Linden: No, I'm pretty certain that will need to spec, down to bits on the wire, how the region and agent communicate back to the viewer :-)
[8:55] Morgaine Dinova: Any TCP-based scheme can be based on HTTP ... just keep the TCP stream from terminating and Bob's your uncle.
[8:56] Tao Takashi: #1 is #4 ;-) just say event queue = different format and HTTP = TCP ;-)
[8:56] Morgaine Dinova: Aye
[8:56] Zero Linden: Well, let's ditch XMPP and AMQP first -
[8:56] Tao Takashi: what's different between our event queue and Comet btw?
[8:56] Morgaine Dinova: Cool :-)
[8:57] Tao Takashi: k
[8:57] Morgaine Dinova: Zero: the reasons for ditching them need to be expressed in the wiki pls, otherwise the question will continually reapper.
[8:57] Zero Linden: AMQP is a message queue system that is not standardized - it is based on what bank comapnies do for routing inside their systems
[8:57] Zero Linden: Yes, Morgaine I'll add it there
[8:57] Zero Linden: too
[8:58] Tao Takashi: but should those reasons be in the spec?
[8:58] Zero Linden: AMQP is a very compact binary protocol - but is fully over blown: Each connection has channels of messages, each channel ahs tracks of messages
[8:58] Tao Takashi: or in the additional "spec explained" doc?
[8:58] Zero Linden: the queuing structure is dynamically reconfigurable
[8:58] Zero Linden: etc....
[8:58] Morgaine Dinova: No, the spec is a spec, not the research that went into creating it.
[8:58] Zero Linden: Tao - no those reasons should not be in the spec
[8:58] Tao Takashi: k
[8:58] Tao Takashi: that's why I thought :)
[8:58] Tao Takashi: what
[8:58] Morgaine Dinova: The reasons definitely ned to be justified, but not in the spec.
[8:59] Tao Takashi: from the description you have AMQP already sounds like fun to implement ;)
[8:59] Zero Linden: While AMQP is designed for high performance systems, the protocol itself, other than being very tightly encoded binary, doesn't actually aide in that
[8:59] Tao Takashi: have = gave (something's wrong today with my keyboard)
[9:00] Zero Linden: it is the implementations that make it so... and I don't think for these single point-to-point communication needs, we'd want to put a full AMQP system in the viewr and the regions
[9:00] Zero Linden: Tao - and I haven't even gotten to the classes of mesaage queues, the instances of message queues, the classes of exchanges, the instances of exchanges, the dispositions.....
[9:01] Arawn Spitteler: doesn't know if this is relative to the discussion, but just had a thought: Bilocation might be the paradigm to solve the Crash on TP, as well as the scaling comparable of TP between protocols.
[9:01] Morgaine Dinova: I'd like the protocol page to have "Rationale" links alongside its current "Discuss" links. The "Rationale" would be "best current understanding for the decision", and would not be a discussion .. you'd discuss in the "Discuss" section.
[9:01] Zero Linden: it is all actually sort of cool - but it is like attacking this problem with a surgical team
[9:02] Zero Linden: One of my favorite books of all time is "XML The Annotated Specification"
[9:02] Morgaine Dinova: OK. Prolly enough on AMQP for now
[9:02] Zero Linden: it is an interleaving of the text of the spec with rationale, examples, and exposition
[9:02] Zero Linden: Now, XMPP is a standard and has many impmentations
[9:02] Morgaine Dinova: Nice. I don't have that book
[9:03] Zero Linden: But, XMPP makes many assumptions that just aren't true here: Like your identity is tied, permenantly, to a host name
[9:04] Zero Linden: and your messages MUST go thorugh that host
[9:04] Morgaine Dinova: Indeed. It's not a generic transport. It's a transport with a VERY specific semantic implied.
[9:04] Zero Linden: The messages and presence are very IM, and don't have the richness of IM or presence in SL.... but they could be augmented, since everything is an XML fragment and they allow you to extend via namespaces
[9:05] Zero Linden: Now, we *could* use it soley as a transport, and do something like create temporary identities for the viewer for it to connect to the region....
[9:05] Zero Linden: but that is sort of not really using XMPP as XMPP - soley as a way to send fragments of XML around
[9:06] Zero Linden: and at that point, you're not really gaining any benefit
[9:06] Zero Linden: as far as I can see
[9:06] Zero Linden: and the setup phase is actually longer than it would be with capabilities and the event queue (!)
[9:07] Morgaine Dinova: While I agree with all of that re XMPP, using it would have one immense benefit: it would force you to decouple SL IM strongly from the rest of SL.
[9:07] Zero Linden: (XMPP preamble -> TLS -> XMPP preamble again -> SASL -> XMPP preamble again -> XMPP binding -> XMPP preamble again -> XMPP message exchange)
[9:07] Saijanai Kuhn: What happens once you're talking about a meta-grid? Do groups cross grid boundaries?
[9:07] Morgaine Dinova: waves to Sai
[9:07] Saijanai Kuhn: waves
[9:07] Saijanai Kuhn: back
[9:08] Zero Linden: except that, Morgain, XMPP doesn't allow the concept of your avatar roaming. Your IM would have to become permenently tied to a host name
[9:08] Zero Linden: It is like e-mail - folks can route to you (though, strangely, that isn't (!) guarunteed by the protocol)
[9:09] Zero Linden: but you can move around - you must always connect to your identity host....
[9:09] Zero Linden: SO -
[9:09] Saijanai Kuhn: doesn't that apply the same as an agent domain however?
[9:09] Arawn Spitteler: So, Cross Grid Groups, where my memebership in Paetheion would be one, rather than two seperate, might follow a Jocko Paradigm
[9:10] Zero Linden: Well, in the protocol, the inital contact is to a fixed host (your agent domain), but you are quickly given a seed cap - and that can be anywhere
[9:10] Zero Linden: this makes it very easy for the agent domain (and region domain) to load balance
[9:10] Zero Linden: The capability gives us the ability to push the connection point around
[9:11] Saijanai Kuhn: We're talking SL here, as opposed to XMPP
[9:11] Zero Linden: yes
[9:11] Zero Linden: which is why I'm not a huge fan of XMPP -- though I can easily imagine that agent domains could offer XMPP access to your IM stream
[9:11] Morgaine Dinova: Yeah, we're getting slightly diverted by the fact that XMPP is IM by nature, and here we're talking about all transport needs.
[9:11] Zero Linden: but I don't think it is going to work for passing region object updates and the like
[9:12] Morgaine Dinova: So ... tentatively cross XMPP off, and put reasons on the wiki in a rationale area.
[9:12] Saijanai Kuhn: WHich is a peculiar thing about SL. That IM is used for so many things
[9:13] Morgaine Dinova: is trying to get back to event queues :-)
[9:13] Zero Linden: Well, let's get back there!
[9:13] Saijanai Kuhn: AH Event QUeues!
[9:13] Morgaine Dinova: Hehe
[9:13] Saijanai Kuhn: (paraphrasing Jon Pertwe in a Funny THing Happened...)
[9:13] Zero Linden: So - I don't want to compare Event Queues to COMET - I didn't really reference COMET in the description
[9:14] Morgaine Dinova: Zero: did your read my comments on the Event Queues section?
[9:14] Zero Linden: So - there are three things I think need clarifying about Event Queue
[9:14] Saijanai Kuhn: That cornfused me initially. I thought I had to close it every time when I first wrote my script
[9:14] Tao Takashi: but mentioning Comet would make it more familiar again to outsiders. Otherwise: new concept => "uuuh, hard to learn" => no implementations
[9:14] Zero Linden: yes, M. - I ahve read them and have them up on my screen now
[9:14] Morgaine Dinova: Cool, they're too long to repeat :-)
[9:15] Saijanai Kuhn: when are you adding a multi-media web board here?
[9:15] Zero Linden: but the COMET pages are very specific to AJAXy things
[9:15] Zero Linden: Oh - Saijanai - good idea!
[9:15] Tao Takashi: well, one can at least compare it to it maybe
[9:15] Morgaine Dinova: Since COMET is the reference implementation of long poll, unless stated then their semantic for long poll applies. That's the danger.
[9:15] Morgaine Dinova: And it hasn't been stated to differ.
[9:15] Zero Linden: SO
[9:15] Saijanai Kuhn: Tao, its easy enough to implement. We can refer folks to python snippets, etc., just as we do for login
[9:16] Zero Linden: I like that EventQueue is defined in terms of pure HTTP -
[9:16] Tao Takashi: well, before you start implementing you need to understand the spec ;_)
[9:16] Zero Linden: That way it "just works" with all existing libraries, tools, caches, etc....
[9:16] Saijanai Kuhn: sure, but you state the spec, give a pretty picture, and say "here's one or more working examples"
[9:16] Tao Takashi: so what is the difference between our event queue and the long poll of Comet? (is there a reference implementation right now anyway?)
[9:16] Zero Linden: But it is defined with the knowledge that TWO techniques will make it work
[9:17] Zero Linden: those techniques are
[9:17] Tao Takashi: I think Comet can still be mentioned, even if we then state what's different (at least in the explanatory doc)
[9:17] Morgaine Dinova: Zero: wrong! That way it "just works" with all of those in a true polling implementation, which would be a total disaster for event comms. Aka. too slow by orders of magnitude.
[9:18] Zero Linden: Morgain- I disagree....
[9:18] Tao Takashi: fight!
[9:18] Morgaine Dinova: Th TCP stream has to stay open until there is a termination event, by request or by going down.
[9:18] Saijanai Kuhn: Morgaine thats the situation as it stands
[9:18] Morgaine Dinova: Otherwise all your select() and epol() etc are shafted
[9:18] Zero Linden: Yes - and most HTTP libraries support this or just do it automatically
[9:18] Zero Linden: !
[9:18] Zero Linden: like, libCurl, say
[9:18] Zero Linden: So the two things you need to do to make it efficient are:
[9:19] Zero Linden: 1) The resource handler needs to, if there are no events, not answer immediatly - but hold the request open for some period of time, waiting for events to arrive - and when they do, then reply
[9:20] Zero Linden: 2) The client side, the invoker of the resource, needs to use HTTP 1.1 and Keep-Alive, so the subsquent requests will not require a new TCP (and SSL) establishment
[9:20] Morgaine Dinova: Zero: but that is *NOT* what the COMET spec for long poll say!!!!! That's why I keep stating that you need to specify it in the protocol that non-termination of the events TCP stream is the expected semantic, unlike that in COMET.
[9:20] Zero Linden: now #1 is much more important than #2 -
[9:21] Zero Linden: since the bulk of the idle time is there
[9:21] Zero Linden: but #2 is an overhead reduction and so is also important
[9:21] Saijanai Kuhn: Morgaine, the reference to Comet is simply bogus. That's why Zero left it out
[9:21] Zero Linden: Now - both these assumptions are compatible with HTTP 1.1
[9:21] Morgaine Dinova: The COMET spec for long poll says "terminate TCP stream as soon as an item is returned".
[9:21] Zero Linden: Good - let's never speak of COMET again
[9:22] Zero Linden: :-)
[9:22] Saijanai Kuhn: one thing I'm NOT sure of is "Keep Alive" --I don't know if my Python lib is using that automatically or not
[9:22] Morgaine Dinova: Sai: COMET is the defining site for long poll. You can't "just leave it out", since we have no spec for our semantic. COMET applies by default.
[9:22] Zero Linden: I say - use Keep-Alive - which, if youa re using a library that does HTTP 1.1, will happen automatically!
[9:22] Saijanai Kuhn: OK.
[9:22] Zero Linden: though I admit you have to use the libary in such a way as to let it do that.....
[9:23] Saijanai Kuhn: I suspect thats the default use/
[9:23] Saijanai Kuhn: since it seems to work without me worrying about it
[9:23] Zero Linden: True, ti is the first google hit for "long poll" HTTP
[9:23] Morgaine Dinova: Zero: I'm happy with that, if we define our long poll semantic. People can't just pull a spec out of thin air. They'll Google for it, and find the COMET spec for long poll.
[9:24] Saijanai Kuhn: actually, I think WHich referred me to it at one point as a reference and thats where I got confused. The spec said one thing, the reference said another
[9:24] Zero Linden: I say, let's call it something else then -
[9:24] Morgaine Dinova: Goog!
[9:24] Morgaine Dinova: Good!
[9:24] Saijanai Kuhn: Goog works for me...
[9:24] Morgaine Dinova: lol
[9:24] Zero Linden: Now #1 is doable easily in any server framework that is multi-threaded (cooperative threads, or 'real' threads) -
[9:25] Tao Takashi: the comet spec does not say this, I think
[9:25] Tao Takashi: as Jacob states in one of the comments, Keep-Alive still applies
[9:25] Zero Linden: It would be hard in a pure CGI environment - but I think we can agree that implemetning a region via CGI would be not more than an academic exercise
[9:26] Tao Takashi: I mean, those websites have the same problem, they want fast events ;-)
[9:26] Zero Linden: actually, that first Google hit about Comet expressly says "Avoids HTTP & TCP/IP set-up and tear-down"
[9:26] Saijanai Kuhn: well we use CAPs in a way thats slightly different than a standard sever use of PATH
[9:26] Zero Linden: "Single connection is re-used"
[9:27] Tao Takashi: Jacob: "With Keep-Alive, it is indeed possible to send multiple requests over a single connection."
[9:27] Saijanai Kuhn: I think I ended up in wiki to be honest
[9:27] Tao Takashi: [2]
[9:27] Morgaine Dinova: Only a non-threaded, single-core implementation needs to *really* poll. We're going to have 8/16/etc-core machine on every desktop soon, so real polling will be ridiculous. That's why we need to assume a permanent TCP connection for event delivery, And *state* that that's the intention.
[9:27] Zero Linden: BUT anyway
[9:27] Tao Takashi: my aim is just to keep concept count down ;-)
[9:28] Zero Linden: No, the reason we don't state it is so that we can be compatible with a wide variety of implementations and circumstances
[9:28] Morgaine Dinova: Tao: you misread I think. While COMET keeps only one (or 2 in transient) connection open, it doesso by terminating one and opening a sucessor, for every result returned.
[9:29] Zero Linden: For example, I can imagine a minimal feature client that only does some things, - it might be impelemented in a very simple fashion and not have keep-alive available
[9:29] Zero Linden: (for exmaple, if it is a set of shell scripts....)
[9:29] Tao Takashi: well, he says that the connection is reused but the request is ended
[9:30] Morgaine Dinova: Zero: keepaliv achieves nothing if the serner end terminates the TCP stream on returning an event.
[9:30] Tao Takashi: "As you say, it is only the request which is finished, and not necessarily the connection."
[9:30] Zero Linden: Morgaine - right - it doesn't
[9:30] Tao Takashi: and so it seems to me mainly a question whether you use keep-alive or not if it's reused, it's long-poll in both cases
[9:30] Zero Linden: but I think we should allow the sending end to terminate when it needs
[9:30] Zero Linden: basing it purly on HTTP makes this resliant
[9:31] Zero Linden: for example - many web server frameworks do support keep-alive, but terminate after some configurable number of transactions
[9:31] Zero Linden: that's fine -
[9:31] Zero Linden: the client side will just reconnect
[9:31] Saijanai Kuhn: regardless, its not Comet. Its easy enough to NOT terminate the connection. ONce you "get it" you don't keep sending "done = TRUE" after every request. ENd of story
[9:31] Tao Takashi: so maybe we can make a list of requirements for this technique and then we can check afterwards if something really is different from long-poll?
[9:31] Morgaine Dinova: Zero: certainly. But there is a world of difference between terminating "when it needs" on sim going down, and "when it needs" after every event transmitted. I want to be sure that the latter is never assumed to be default operation.
[9:31] Zero Linden: (well, actually, keep-alive: 1)
[9:32] Morgaine Dinova: Sai: you're talking about client end. I'm talking about server end.
[9:32] Zero Linden: What if we say "Both clients and resource handlers for an Event Queue SHOULD use HTTP 1.1 and Keep-Alive to keep the established connection open as long as possible."
[9:33] Zero Linden: or some such
[9:33] Tao Takashi: sounds good to me
[9:33] Morgaine Dinova: Zero: if you outline what the expected "as long as possible is", sure, that would be good.
[9:33] Tao Takashi: is there actually a standard for Comet?
[9:34] Zero Linden: and "Resource hanlders for event_queue/get, if there are no events pending, SHOULD wait at least <x> seconds for events to arrive, before returing an empty event list."
[9:34] Zero Linden: Morgain - I think we'd have to get clearer on that, as well as the value of <x>, as experience provides
[9:34] Zero Linden: Right now we are using <x> of 30, and I think it is a little short
[9:35] Morgaine Dinova: Zero: it's not the termination on lack of evnts that is the problem. It's the termination on returning an event.
[9:35] Zero Linden: Well, that is the first 'SHOULD' cluase
[9:36] Zero Linden: But allowing it to close if needed (for example, if it is running out of sockets.... or as some systems do to guard against memory leaks), should be acceptable
[9:36] JetZep Zabelin: kewl.. its Elvis Presley
[9:36] EIvis Presley: Uhhh huhhh
[9:36] Zero Linden: I should also note, it isn't actually the resource hanlder that has to do keep-alive , it is the capability host
[9:37] Morgaine Dinova: Zero: certainly. termination on exception conditions is important. It's the termination on returning an event that is the only problem.
[9:37] Zero Linden: which, actually makes it more useful, as it improves not just event queue, but all resrouce invocations from the viewer to a given capability host (in our system, one per region)
[9:37] Zero Linden: OH
[9:37] Zero Linden: look at the time
[9:37] Zero Linden: Thanks all for coming
[9:38] Zero Linden: I'll put my XMPP and AMQP findings in the wiki (in discuss for now,)
[9:38] Morgaine Dinova: Buh, we *still* haven't affirmed that the server won't by defeault terminate the stream afte every event returned.
[9:38] Zero Linden: and I think we have a way of talking about Event Queues that might make this clearer for all
[9:38] Zero Linden: Later

User:Zero Linden/Office Hours/2008 Mar 20

Navigation menu

Search