[00:07] the_undefined has joined the channel
[00:10] CIA-28: node: 03Michaeljohn Clement 07master * r485823f 10/ (lib/http.js test/mjsunit/test-http-server.js): 
[00:10] CIA-28: node: fixed HTTP duplicated header bug
[00:10] CIA-28: node: added test case for HTTP duplicated header bug on keepalive - http://bit.ly/8nK6yX
[00:11] elliottcable: oh snap
[00:11] elliottcable: that sounds like the problem I was having a while back!
[00:14] inimino: ^.^
[00:14] the_undefined: ryah: http://groups.google.com/group/nodejs/browse_thread/thread/6398ee8d78dd16a3 -> did you push 485823f yet?
[00:14] elliottcable: the_undefined: read up d0:
[00:14] elliottcable: the_undefined: unless you have CIA-28 on ignore
[00:14] the_undefined: elliottcable: I just came in
[00:14] the_undefined: left me read the logs
[00:15] elliottcable: the_undefined: it was after you came in
[00:15] the_undefined: oh wait
[00:15] elliottcable: hahaha
[00:15] the_undefined: http://groups.google.com/group/nodejs/browse_thread/thread/6398ee8d78dd16a3
[00:15] the_undefined: ryah was referring to 485823f, but 485823f is something completely different
[00:15] elliottcable: hahah
[00:15] elliottcable: okay
[00:15] elliottcable: l’oops
[00:20] elliottcable: erikcorry|away: you still away?
[00:24] the_undefined: does anybody know what I need to build node-crypto?
[00:24] the_undefined: configure says: Checking for library ssl                 : not found
[00:24] the_undefined: and my build fails with all kinds of errors
[00:24] the_undefined: but I have openssl installed
[00:24] the_undefined: (ubuntu 9.10)
[00:38] crux has joined the channel
[00:44] jed has joined the channel
[01:17] xantus: yo
[01:17] xantus: hmm, what happened to the_undefined
[01:18] xantus: libssl-dev
[01:20] sudoer has joined the channel
[01:33] shfx has joined the channel
[01:52] JimBastard has joined the channel
[01:53] JimBastard: what exactly are rss and vsize attributes of process.memoryUsage()
[01:56] inimino: resident and virtual I would guess
[01:57] inimino: JimBastard: you can see if they correspond with top
[01:57] JimBastard: got ya
[01:57] JimBastard: http://maraksquires.com:8000/debug.html
[01:58] kriskowal has joined the channel
[01:58] inimino: rss is resident set size
[01:58] JimBastard: k
[01:59] inimino: nice
[01:59] JimBastard: then http://maraksquires.com:8000/session.html
[01:59] JimBastard: im having some issues with the current node_debug
[01:59] JimBastard: not really sure what to do
[02:01] JimBastard: i think i need a good databinding engine
[02:04] mtotheikle has joined the channel
[02:06] Yuffster has joined the channel
[02:06] mtotheikle has left the channel
[02:10] eddanger has joined the channel
[02:12] soveran has joined the channel
[02:17] Connorhd has joined the channel
[02:19] JimBastard: i still cant figure out how to access my post variables
[02:20] JimBastard: i got the uri and method
[02:22] inimino: well, POST just includes a body, it could really be in any format
[02:22] inimino: JimBastard: is this for the debugger?
[02:22] JimBastard: well, trying to do a login
[02:24] inimino: ah
[02:24] inimino: you got the request body in a variable?
[02:24] JimBastard: request.body?
[02:24] JimBastard: i have the request object
[02:24] inimino: it's an event
[02:25] inimino: you listen for the event
[02:25] inimino: collect the chunks
[02:25] inimino: append them together
[02:25] inimino: and then use that
[02:25] JimBastard: whats the listener
[02:26] inimino: body
[02:26] inimino: and "complete"
[02:27] inimino: http://www.pastie.org/728530
[02:27] inimino: you can probably delete the first three lines of that function
[02:27] JimBastard: thanks
[02:28] inimino: and you probably don't want to use 'binary'
[02:28] JimBastard: semicolons
[02:28] JimBastard: they only 5cents a piece
[02:34] onar_ has joined the channel
[02:36] hassox has joined the channel
[02:37] hassox has left the channel
[02:44] hassox has joined the channel
[02:51] jed has joined the channel
[03:21] malkomalko_ has joined the channel
[03:45] jed has joined the channel
[03:48] JimBastard has joined the channel
[04:02] RayMorgan has joined the channel
[04:06] eddanger has joined the channel
[04:18] binary42 has joined the channel
[04:29] jbowman has joined the channel
[04:33] jbowman has joined the channel
[05:10] xantus_ has joined the channel
[05:14] JoePeck has joined the channel
[05:15] Achilles has joined the channel
[05:17] Achilles has left the channel
[05:58] fictorial has joined the channel
[06:20] eddanger has joined the channel
[06:22] ryah: oops looks like i didn't put up felix's changes
[07:11] JimBastard has joined the channel
[07:11] JimBastard: how do i add an event to on error of posix.cat()
[07:11] ryah: JimBastard: .addErrback
[07:12] JimBastard: hey ryah! im looking in the docs, what is the sample syntax?
[07:12] Wes- has joined the channel
[07:12] ryah: JimBastard: posix.cat("hello.txt").addErrback(function () { }) 
[07:12] ryah: (i guess)
[07:13] Micheil: morning ryah & JimBastard
[07:16] ryah: morning
[07:19] JimBastard: that worked, thanks ryah
[07:32] cmlenz has joined the channel
[07:39] JimBastard: is there any easy way to get post variables besides breaking the request body up
[07:40] CIA-28: node: 03Ryan Dahl 07master * r7538e70 10/ (lib/http.js src/node_http.cc): Expose versionMajor versionMinor to http messages - http://bit.ly/4PsBY5
[07:40] CIA-28: node: 03Ryan Dahl 07master * rc5d8238 10/ (lib/http.js test/mjsunit/test-http-1.0.js): 
[07:40] CIA-28: node: Bugfix: Don't use chunked encoding for 1.0 requests.
[07:40] CIA-28: node: http://groups.google.com/group/nodejs/browse_thread/thread/b2edb76691b1848c - http://bit.ly/5Y9udY
[07:45] ciju has joined the channel
[08:01] rtomayko has joined the channel
[10:02] the_undefined has joined the channel
[10:13] cmlenz has joined the channel
[10:29] saikko has joined the channel
[11:22] Connorhd has joined the channel
[11:24] the_undefined has joined the channel
[11:33] Biscuits has joined the channel
[11:46] ciju_ has joined the channel
[11:54] damien_ has joined the channel
[12:22] soveran has joined the channel
[12:29] soveran has joined the channel
[12:40] mikekelly: JimBastard: there's really no such thing as 'post variables'
[12:41] mikekelly: as far as HTTP in concerned
[12:41] mikekelly: in/is
[12:43] mikekelly: same with URL 'query variables'
[12:47] the_undefined has joined the channel
[12:56] edds has joined the channel
[13:35] mikekelly has joined the channel
[13:57] dam has joined the channel
[14:30] rakeshpai has joined the channel
[14:32] rakeshpai: Need some quick help. Let's say I have a method called connectIfRequired that checks if a TCP connection exists, and if not, it attempts to establish a TCP connection. How can I handle an onsuccess in such a case? It's trivial if the connection doesn't exist (I simply use the tcp connection onsuccess), but if it does exist, I need to be able to fake an onsuccess so that the method signature remains the same. Any idea how?
[14:33] rakeshpai: is this a candidate for using promises?
[14:54] rakeshpai: anyone here?
[14:56] ryah: rakeshpai: maybe use connection.readyState?
[14:57] rakeshpai: ryah: No, that's not what I meant
[14:57] rakeshpai: let me try explaining again
[14:58] rakeshpai: I guess what I'm talking about is something like dojo's Deferred
[14:58] ryah: ah i think i understand
[14:59] ryah: you can do something like setTimeout(onsuccess, 0)  
[14:59] ryah: if it's already there
[15:00] ryah: then on the next loop of the event loop it will make the callback
[15:00] rakeshpai: ryah: true, but that's still not quite like Deferred, right - in dojo, you can pass around the deferred object, and let interested parties attach callbacks. Would that work with the setTimeout approach as well?
[15:00] rakeshpai: I guess it would, right?
[15:01] rakeshpai: well, at least it suits my need at this moment. However, maybe we should think about porting deferreds to node - it makes async programming a breeze
[15:02] ryah: depends on the interfaceyou want i guess. you can do setTimeout(function () { promise.emitSuccess(); }, 0)
[15:03] rakeshpai: ryah: Yeah... Like I said, that works for me for the moment. Thanks
[15:04] ryah: how would it be different with dojo's deferreds?
[15:11] CIA-28: node: 03Ryan Dahl 07master * rc8b6ef2 10/ (99 files in 13 dirs): upgrade v8 to 2.0.3 - http://bit.ly/5Jl9fj
[15:18] rakeshpai: ryah: let's say I get a deferred from one method, and then depending on another async call's results, I want to add a callback to the deferred. It works with dojo's system. Not with setTimeout(onsuccess, 0)
[15:19] soveran has joined the channel
[15:20] rakeshpai: I guess all that deferred does internally anyway is just keep track of if a event has happened or not. If it has, all subsequent event handlers are called immediately as they are attached. promises aren't quite the same thing, right?
[15:26] rakeshpai: ryah: congrats on the v8 upgrade :)
[15:39] binary42 has joined the channel
[15:49] edds has left the channel
[16:04] ryah: rakeshpai: how is that different from node's promise?
[16:05] rakeshpai: ryah: because promise afaik doesn't keep track of whether the event has fired. Handlers attached after the event has occurred don't get called.
[16:06] ryah: ah okay.. hm interesting. so if someone does deferred.addCallback() after the event has fired, it will be called immediately?
[16:06] rakeshpai: ryah: yeah
[16:06] ryah: that's a nice behavior
[16:07] ryah: clearly dojo has thought through their deferred api a lot more than commonjs's spec on the wiki :)
[16:07] rakeshpai: it makes it very easy to work with - one doesn't need to keep track in code about whether the event has occurred or not, and either call immediately, or attach a callback
[16:07] ryah: yeah
[16:08] rakeshpai: ryah: is it? I haven't looked at the spec, but this sounds like the most intuitive behaviour to use in a deferred/promise kind of api.
[16:09] inimino: hm... didn't know that about deferred
[16:09] ryah: i wonder if dojo has some tests that we could grab that define it's behavior abstractly
[16:09] rakeshpai: effectively, deferreds guarantee that a callback or an errback will be executed, irrespective of when it was attached to the deferred object.
[16:10] inimino: I have a lot of function that return either an immediate result (e.g. from a cache) or a promise
[16:11] rakeshpai: inimino: in dojo, you'd just return a deferred, and then attach a callback - it doesn't matter if inside your function you can get data immediately or async. If you get it immediately, you could already call the equivalent of .emitSuccess on the deferred and return it.
[16:12] rakeshpai: subsequent addCallback handlers will get executed as they are attached, if you've already called the equivalent of .emitSuccess
[16:13] inimino: right
[16:13] inimino: that means keeping any arguments around in memory until the promise itself goes out of scope
[16:13] rakeshpai: yeah
[16:14] rakeshpai: I guess you take a hit there.
[16:14] inimino: and a little extra overhead in addListener() and when calling the handlers
[16:15] rakeshpai: true, but a easier-to-work-with api
[16:16] the_undefined: rakeshpai: I'm porting dojo deferreds to nodejs
[16:17] the_undefined: I'm also thinking about possible sugar to ease the aggregation of multiple deferreds running in parallel
[16:17] rakeshpai: the_undefined: cool... do you think this should be something built into node?
[16:18] the_undefined: rakeshpai: yes, but reasonable discussion should happen first
[16:18] the_undefined: I'm making it a standalone module
[16:18] the_undefined: and then I'll start a branch that refactors some of node's core to use it
[16:18] the_undefined: and play with it
[16:18] the_undefined: to see how it feels
[16:18] the_undefined: but I really love the API
[16:19] the_undefined: it's awesome
[16:19] the_undefined: especially the fact that each callback acts as a filter that can permutate the initial result
[16:19] the_undefined: makes it very easy to compose complex behavior on top of the core I/O deferreds that node would emit
[16:19] rakeshpai: I was just going to mention that
[16:19] the_undefined: let me push my current work online
[16:20] the_undefined: I won't be able to work on it over the weekend
[16:20] rakeshpai: inimino, ryah: that's another benefit of deferreds
[16:21] ryah: the_undefined: just so you know my plan is to change the c++ interface to file system stuff so that it doesn't use promises
[16:21] ryah: it will be sometihng like process.fs.write(15, "hello", function ( ) { })
[16:21] ryah: just a callback
[16:22] the_undefined: ryah: don't do that, what's your thinking behind it?
[16:22] the_undefined: I don't mind if you add parameter #3 as a convenience
[16:22] the_undefined: for addCallback
[16:22] ryah: then it will be wrapped using promises
[16:22] ryah: so that promises can be implmented completely in javasript
[16:22] the_undefined: ah
[16:22] the_undefined: so that was the only reason they are partially in C++ right now?
[16:23] inimino: I prefer that
[16:23] inimino: especially if deferreds are going to happen
[16:23] ryah: basically
[16:23] the_undefined: ok, I support anything making promises / deferreds a pure JavaScript construct
[16:23] ryah: generally i'm trying to put more stuff in javascript by rwapping internal c++ interfaces
[16:23] inimino: CPS is much more flexible and any of these others can be implemented on top trivially
[16:23] the_undefined: but in general I'd like the API to be consistent :)
[16:23] rakeshpai: I agree with the_undefined 
[16:23] rakeshpai: @ consistency
[16:24] ryah: the apis won't change 
[16:24] inimino: or whatever else better comes along API-wise
[16:24] ryah: or maybe slightly
[16:24] ryah: at the moment promises are really complicated in node just cause it's tied up in c++ stuff
[16:24] ryah: half in js, half in c++
[16:25] rakeshpai: ryah: I'd go so far as to say that we should think about deferreds instead. Promises are almost there already. Just some book-keeping needs be added
[16:25] rakeshpai: of course, I might be biased - I love dojo's apis
[16:26] ryah: rakeshpai: i think we'll be implementing dojo's semantics. they'll probably still be called promises though
[16:26] ryah: or maybe we can rename it *shrug*
[16:27] rakeshpai: cool... in this case at least, it doesn't matter what it's called.
[16:27] frodenius: i would prefer 'promise' to keep it's eventemitter semantics
[16:28] ryah: that can probably be maintained
[16:28] ryah: maybe
[16:28] the_undefined: http://github.com/felixge/node-deferred
[16:30] the_undefined: I think we should name them Promise as well
[16:30] the_undefined: renaming to Deferreds would break everybodies node code for no good reason
[16:30] the_undefined: plus there are a few things I'd like to propose we should add to deferreds
[16:30] ciju_ has joined the channel
[16:30] the_undefined: I'm thinking about some sugar like jed uses for fab
[16:31] the_undefined: http://gist.github.com/249748
[16:31] the_undefined: this would execute all 3 db queries at the same time and then pass them to the 'results' function all together
[16:32] ryah: cool
[16:32] the_undefined: not 100% certain this is how it should be, but I think there should be an easy way to combine the results from several deferreds running in parallel easily
[16:33] ryah: so promise is a function?
[16:33] the_undefined: without high cyclomatic complexity 
[16:33] the_undefined: yes
[16:33] the_undefined: a function with properties
[16:33] the_undefined: the function being a reference to one of the properties itself
[16:33] frodenius: nice idea
[16:33] ryah:     p(results); // == {result1: result1, result2: result2, result3: result}
[16:33] the_undefined: not mine, jed did that with fab
[16:33] ryah: ^-- doesn't seem right. it should only be the results of result3
[16:33] the_undefined: ryah: notice how the last call is just ('result3')
[16:34] the_undefined: this indicates the end of the chain
[16:34] ryah: oh right
[16:34] the_undefined: I could have formatted this nicer
[16:34] the_undefined: :)
[16:34] the_undefined: anyway, inspiration comes from here: http://github.com/jed/fab
[16:34] the_undefined: I really really think this is a cool way to use javascript
[16:35] ryah: i think it should be like this: http://gist.github.com/249750
[16:35] the_undefined: ryah: the formatting?
[16:35] the_undefined: yeah
[16:35] ryah: using addCallback to get the combined result
[16:35] the_undefined: that would work
[16:36] the_undefined: I'm thinking that this construct should maybe be a construct on top of Deferreds
[16:37] ryah: well - the question is if this should chain the promises - doing each in order - or if it should execute them all at once and aggregate the results
[16:37] inimino: I don't think this should be in core node
[16:37] ryah: both are common use cases
[16:38] the_undefined: http://gist.github.com/249748
[16:39] the_undefined: I like this
[16:39] inimino: it's a nice syntax but I would prefer the low-level node API stay in a more traditional style
[16:39] inimino: and something that doesn't require lots of function overloading
[16:39] ryah: inimino: you have a point
[16:39] the_undefined: ryah, we could have: (sequence) and (group)
[16:40] the_undefined: as the construct
[16:40] rakeshpai: I agree with ryah and inimino. This looks like something that can be built on top of deferreds
[16:40] inimino: if the raw callback-based API is exposed to JavaScript this kind of sugar can be implemented on top without any extra performance hit
[16:40] the_undefined: inimino: me too, that's why I'm proposing to use Deferreds on the low level, and add some sugar like my latest paste as a module
[16:41] the_undefined: (notice how you could add a addCallback to any of the db queries to alter the result or do something with it even before all the others finish)
[16:41] the_undefined: (you could also still pass in a function and it would use its return value, which could also be a deferred)
[16:42] inimino: I'd prefer to have the low-level be the even lower CPS level, and Promises, Deferreds, or a fab-style API can be modules
[16:42] the_undefined: inimino: CPS?
[16:43] inimino: continuation-passing style
[16:43] the_undefined: (just noticed I had two "addCallback" in my latest paste, removed)
[16:43] the_undefined: inimino: what's that?
[16:43] the_undefined: just providing a callback?
[16:43] rakeshpai: inimino: That's a tough call to take. If it gets too low level, it'll be a hard api to work with
[16:45] inimino: the_undefined: yeah, CPS I guess is the style of programming you end up doing with an API of that sort, like process.fs.write(..., function(){})
[16:45] the_undefined: inimino: yeah
[16:45] the_undefined: well, maybe we should consider node's public API to have 2 layers
[16:45] the_undefined: kind of like git: porcelain and plumbing 
[16:46] inimino: rakeshpai: yes, it's not the most convenient API, but it's fully expressive and doesn't imply any performance hit
[16:46] the_undefined: where the high level porcelain stuff returns deferreds
[16:46] the_undefined: and the really low level stuff is CPS
[16:46] inimino: I think that would be awesome
[16:46] the_undefined: to me fs.write is low level enough that I wouldn't write most of my modules on top of it, but rather the file module
[16:47] inimino: yes
[16:47] the_undefined: we just need to make sure everything has a low-level and high level approach
[16:47] the_undefined: the way http client works right now is kinda low level
[16:47] the_undefined: it should be made probably even more low level
[16:47] the_undefined: but provide some nice REST inspired thing on top
[16:47] rakeshpai: I'm wondering if this will end up being too low level to necessitate the use of frameworks, thus removing the performance benefits in the first place
[16:48] inimino: currently most people are probably writing their own wrappers around the posix stuff, but the next generation won't
[16:48] the_undefined: rakeshpai: no, it depends on what you do. If you write a web application you don't care about the performance hits of a nice API
[16:48] inimino: s/generation/wave/
[16:48] the_undefined: but if you write something like reddis you do
[16:48] inimino: exactly
[16:48] rakeshpai: hmm... I agree
[16:49] the_undefined: so to me node should have a really stupid non-bocking low level API, and a really nice sugary one one top
[16:49] the_undefined: :)
[16:49] inimino: and the people who write the nice web app frameworks care about making things fast for their users, which is why it's nice to have access to the more low-level API
[16:49] the_undefined: inimino: exactly
[16:49] the_undefined: you just need the option to go deeper
[16:49] rakeshpai: true that
[16:49] the_undefined: so the lowest layer should be very stupid, as close to the C++ connections as possible
[16:50] inimino: yeah, instead of implementing one abstraction on top of another
[16:50] the_undefined: yeah
[16:50] the_undefined: well, now this will all depend on what ryan thinks
[16:50] the_undefined: not sure he'd be excited to make major API changes right now :)
[16:51] inimino: on the plus side, it would simplify the node core :-)
[16:51] rakeshpai: well, it's kinda now or never, right? if node gets deployed enough, it'll be impossible to make api changes
[16:52] ryah_away: yes
[16:52] ryah_away: got about a month left to make major api changes
[16:52] onar_ has joined the channel
[16:52] the_undefined: 
ACTION is not looking forward to refactor transload.it again :D

[16:53] rakeshpai: the_undefined: I'm sure you've thought about that risk when you decided to use a 0.x version of software. ;)
[16:53] the_undefined: rakeshpai: I have :)
[16:53] the_undefined: it's all good
[16:54] inimino: ^.^
[16:54] ciju_ has joined the channel
[16:54] the_undefined: one thing I did do was writing exhaustive unit tests
[16:54] the_undefined: so I usually had a good time upgrading
[16:56] inimino: I've not had much real trouble so far, but this would be a slightly bigger change
[16:57] the_undefined: inimino: what are you working on?
[16:59] inimino: the_undefined: basically this: http://inimino.org/~inimino/blog/text_editor_requirements
[16:59] inimino: the_undefined: most of the node code I have is here: http://boshi.inimino.org/3box/nhttpd/
[17:00] inimino: which is all pretty raw and experimental
[17:00] inimino: but working surprisingly well so far
[17:00] inimino: node is a pleasure to use
[17:00] the_undefined: any demo?
[17:00] the_undefined: online?
[17:01] inimino: not yet, I have a bunch of text editor features at the moment that have no UI
[17:01] the_undefined: inimino: well good luck :)
[17:02] inimino: thanks :)
[17:04] inimino: one of the remaining issues with node is things like chaining lots of promises together
[17:04] inimino: I think there jury is still out on the best kinds of APIs in JavaScript to make that really painless
[17:05] rakeshpai: inimino: what kind of chaining are you referring to?
[17:06] inimino: rakeshpai: like fs.stat.open.write.write.write.close
[17:07] inimino: rakeshpai: currently you end up with a lot of helper functions, or promises nested n levels deep
[17:07] inimino: rakeshpai: and then you have to do things like handle all the extra error callbacks separately
[17:07] inimino: I know Deferreds ease many of these issues
[17:08] inimino: another is having a call that might return an immediate result or a promise, and chaining these
[17:08] rakeshpai: that shouldn't be so hard right? each one returns itself, and internally, it just pushes these items into a list to be processed as and when possible
[17:09] inimino: in general the problem is: making asynchronous code as composable as synchronous code
[17:10] rakeshpai: i know what you mean, though, with the nested handlers. I can see that people will dislike that
[17:10] rakeshpai: even if purely from an aesthetic perspective
[17:10] mtotheikle has joined the channel
[17:11] inimino: it's painful to read and write and painful code tends to contain more bugs
[17:12] rakeshpai: that said, i'd think that this is high-level as well, and shouldn't be in node. It's basically syntactic sugar, and can be slapped on externally
[17:16] inimino: rakeshpai: yes, quite
[17:16] inimino: rakeshpai: btw, I didn't mean chaining as in that particular syntax, I just meant the idea of sequencing promises
[17:17] rakeshpai: I think I know what you mean - it shouldn't be so hard to implement, though we'd only know if the API is good enough if we actually use it a bit
[17:18] inimino: yes
[17:20] inimino: I expect the design of asynchronous APIs to continue to improve for a while
[17:32] mtotheikle has left the channel
[17:37] sudoer has joined the channel
[18:13] aconran has joined the channel
[18:16] isaacs has joined the channel
[18:22] alexiskander has joined the channel
[18:22] ciju_ has joined the channel
[18:25] bentomas has joined the channel
[18:29] Yuffster has joined the channel
[18:30] jed has joined the channel
[18:32] inimino has joined the channel
[18:47] cmlenz has joined the channel
[18:47] the_undefined has joined the channel
[18:47] pdelgallego has joined the channel
[19:00] malkomalko has joined the channel
[19:00] the_undefined has left the channel
[19:00] the_undefined has joined the channel
[19:16] isaacs has joined the channel
[19:22] jtaby_ has joined the channel
[19:22] michaelk^ has joined the channel
[19:40] jed has joined the channel
[19:40] the_undefined has joined the channel
[19:55] jbowman has joined the channel
[20:04] cloudhead has joined the channel
[20:13] malkomalko_ has joined the channel
[20:13] rakeshpai has joined the channel
[20:14] eddanger has joined the channel
[20:26] rakeshpai has joined the channel
[20:28] rakeshpai: hello, node
[20:38] rbranson_ has joined the channel
[21:05] cmlenz has joined the channel
[21:07] jbowman has left the channel
[21:13] edds has joined the channel
[21:20] malkomalko_ has joined the channel
[21:46] isaacs has joined the channel
[21:58] jed_ has joined the channel
[22:06] rakeshpai has joined the channel
[22:23] eddanger has joined the channel
[22:42] sudoer has joined the channel
[23:04] michaelk^ has joined the channel
[23:09] malkomalko has joined the channel
[23:24] fynn has joined the channel
[23:26] chuck has joined the channel
[23:26] chuck: Are there any frameworks for node yet that make Comet easy?
[23:27] fynn has left the channel
[23:42] tapwater has joined the channel