[00:53] jed has joined the channel [01:06] r11t_ has joined the channel [01:47] robrighter has joined the channel [01:59] okito has joined the channel [02:05] jed has joined the channel [02:08] binary42 has joined the channel [02:23] martint-t has joined the channel [03:04] rictic has joined the channel [03:06] rictic has joined the channel [03:10] erichocean has joined the channel [03:10] erichocean: nio [03:19] aho has joined the channel [03:31] sudoer has joined the channel [03:57] bentomas has joined the channel [04:00] hassox has joined the channel [04:01] hassox: allo [04:01] eddanger has joined the channel [04:08] gwoo has joined the channel [04:23] jed: hassox: howdy. [04:23] hassox: gday [04:23] hassox: what's news mate? [04:23] jed: nuffin doin [04:23] jed: how's it down under? [04:23] hassox: hot [04:24] hassox: damn hot today [04:24] hassox: nice with the air con though :) [04:25] jed: -10 [04:25] jed: -10C here in philly. [04:25] hassox: whoa [04:26] hassox: lemme see what it is here [04:26] hassox: 1 sec [04:26] jed: btw, i think you might find my new chaining approach in (fab) interesting. dropping next week. [04:26] hassox: 42ºC here [04:26] jed: heh, wow. [04:26] hassox: got a link? [04:26] jed: naw, not yet. [04:26] jed: still a mess. [04:26] hassox: kk [04:27] hassox: ACTION is just getting a doc together to outline what things need to be considered IMHO when chaining [04:27] jed: i was thinking about taking a jsgi approach, but didn't really like the way it did streaming. [04:28] jed: i think i've found a good way to accommodate async, streaming, and middleware in a pretty simple way. [04:29] jed: looking forward to getting your feedback next week. [04:30] jed: lemme know when you put your doc up, curious to check it out. [04:31] hassox: rgr [04:31] hassox: it's really simple [04:31] hassox: well [04:31] hassox: there's quite a lot of stuff that needs to be considered when chaining [04:45] hassox: jed: some thoughts : http://github.com/hassox/chain/blob/master/REQUIREMENTS.textile [04:46] jed: reading... [04:49] inimino: hassox: typo in your first heading [04:49] hassox: inimino: churs [04:49] hassox: fixed [04:49] hassox: ACTION has typos all over the place [04:49] hassox: I suck at spelling and I haven't worked out how to turn on the checker in vim ;) [04:52] RayMorgan has joined the channel [04:53] hassox: jed: inimino updated the doc to add a new para (4 or 5) on why events are used like they are in chain [04:54] inimino: hassox: how does this work with streaming outpput? [04:54] hassox: inimino: each link can choose to stream [04:54] hassox: there's no requirement to pass things "back up the chain" [04:55] hassox: if a link knows how to respond, it should [04:55] hassox: which means that each link can stream [04:55] hassox: env has the response object in it at env.response so you can do whatever you need to [04:56] hassox: inimino: I think it's important that the linking be as lightweight as possible, and should only be in place so that we can write components that work together [04:56] inimino: hm, ok [04:57] hassox: this is not an attempt to specify django or rails... it's mearly a way to link components together such that they can all play together, but they can also do the cool stuff that node and js lets you do (long connections / streaming) [04:57] jed: so, the most important thing is that the app itself decides where to pass control, instead of returning? [04:57] hassox: k gotta go for 5 and get on my train [04:58] hassox: 1 sec [04:58] inimino: hassox: so if I have a component that does logging, and one that does gzip on the output, and then another one that does streaming... [04:58] inimino: hassox: can I plug all those together? [04:58] eddanger has joined the channel [04:58] inimino: ACTION pauses in mid-sentence [05:00] jamiew has joined the channel [05:00] inimino: bbl [05:08] hassox has joined the channel [05:09] hassox: jed: sorry mate.. train has been delayed 20mins so I'm still here for a bit [05:09] hassox: jed: what was the question again [05:11] jed: hassox: i was just trying to grok the whole thing. [05:11] hassox: ah right [05:11] hassox: ok [05:11] hassox: well once my train gets here, I'll jump back online so we're not interrupted if you like [05:11] jed: (i asked: "so, the most important thing is that the app itself decides where to pass control, instead of returning?") [05:11] hassox: that's _an_ important aspect [05:11] jed: aka, there's no round trip. [05:12] hassox: because we're talking async, we don't _have_ to have a round trip [05:12] hassox: we can choose to have a round trip if we want to see it on the way out [05:12] hassox: or we can just pass it forward and forget about it [05:13] hassox: so say you have a chain of 10 links but only link 2 wants to see it on the way out [05:13] hassox: then only link 2 sees it on the way out [05:15] cadorn has joined the channel [05:15] jed: i see. so all of the relevant data hangs off the env object. [05:15] keeto_ has joined the channel [05:15] hassox: correct [05:16] hassox: ok I think I have to get down for my train now [05:16] hassox: once I get on I'll jump back online [05:16] jed: aight, i might be asleep in a bit, but ping me when you get on, jah? [05:19] Yuffster has joined the channel [05:25] tiglionabbit: the "options" parameter here says it's like the options for tcp.Server, but is that ever explained? http://nodejs.org/api.html#_http [05:32] jed: tiglionabbit: it hasn't been used for a long time. [05:33] jed: tiglionabbit: check line 374 in http.js... it's commented out. [05:33] jed: tiglionabbit: not sure what the status is, but it's not being used now, at least. [05:51] hassox has joined the channel [05:52] hassox: jed: k back [05:53] jed: hassox: hey. [05:54] hassox: jed: k [05:54] jed: hassox: would be cool to see your doc distilled down by the actual API. [05:54] hassox: I"m at your disposal [05:54] jed: hassox: i'm having a hard time figuring how the flow actually works. [05:55] hassox: I suck at dox it's true [05:55] hassox: so [05:55] hassox: a request comes in [05:55] hassox: the request and response are wrapped in an "env" object [05:55] hassox: then this happens to the first link in the chain [05:55] hassox: firstLink.emit("request", env) [05:56] hassox: that's how you pass from one link to another [05:56] hassox: but ther'es an api for doing it [05:56] hassox: env.send(firstLink) [05:56] hassox: make sesne? [05:56] jed: so the second link watches for that event? [05:57] jed: aka, each link subscribes to the one before? [05:57] hassox: no [05:57] hassox: that's what doesn't happen [05:57] hassox: as soon as that happens you have a static structure [05:58] jed: blarg, sorry i'm a little dim. (it's also late here...) [05:59] jed: i'm not sure what you mean by static. [05:59] jed: is the result of Builder.make not static? [05:59] hassox: to be a link you need to setup a listener on yourself for the "request" object [05:59] hassox: event [05:59] hassox: sorry [06:00] hassox: that recieves a single arg, then env [06:00] hassox: someLink.emit("request", env) [06:00] eddanger has joined the channel [06:02] hassox: that causes someLink to act on the env [06:03] hassox: so each link actually listens to itself [06:03] hassox: the result of builder is a static "suggested" route [06:03] hassox: if you put something like a router in place though [06:04] hassox: you could go anywhere the router decides to send you [06:05] jed: so the builder basically sets the default nextApp? [06:08] hassox: if it's done via listeners from the downstream to the upstream objects, you're static. You can only have that one path [06:08] hassox: jed: do you care how it works, or what the api is? [06:08] hassox: at it's heart that's what it does yeah [06:08] hassox: it also turns functions into links and supplies a builder that you can define your stack with gradually [06:08] hassox: but when it "builds the stack" it just sets up a nextApp attribute on all the links [06:10] jed: i think i'm getting it. the README is actually pretty clear too. [06:10] jed: but yeah, APIs are the only way i can truly grok it. [06:11] jed: which is why (fab) has so few methods. i dislike surface area. [06:11] jed: the thing is, a callstack doesn't necessarily mean blocking, does it [06:12] jed: ? [06:13] soveran has joined the channel [06:14] Yuffster has joined the channel [06:14] jed: well, it's past 1am here. gonna call it a night and check it out tomorrow. [06:15] jed: hassox: i definitely think there's a good way to crack the chaining nut. this seems like the best approach so far. [06:15] jed: hassox: aight, chat with ya later. [06:16] hassox: working on that for ou now [06:16] hassox: jed: a call stack does [06:16] hassox: ppl have been working on ways to make it look like a callstack [06:18] elliottcable: hassox: o7 ’sup? [06:26] hassox: IMHO that encourages ppl to write sync code though.. I think it's much better to force async at the lowest level. Let api's layer sync like stuff on top [06:26] hassox: jed: gnight :) [06:27] hassox: hey elliottcable [06:27] hassox: trying to find a document that isn't scary that describes chain [06:27] hassox: choo doing? [06:29] eddanger has joined the channel [06:36] okito has joined the channel [06:50] hassox: jed: still here? [06:50] hassox: jed: http://github.com/hassox/chain/blob/master/API.textile [06:52] mattly has joined the channel [07:14] hassox_ has joined the channel [07:23] okito has joined the channel [07:34] scudco has joined the channel [07:51] mikeal has joined the channel [07:51] hassox has joined the channel [08:19] keeto_ has joined the channel [08:26] tisba has joined the channel [08:52] elliottcable: what’s up, my noder homies? [09:04] rtomayko has joined the channel [09:43] sveimac has joined the channel [09:47] jasondavies has joined the channel [09:59] qFox has joined the channel [10:16] sveimac has joined the channel [10:19] ako has joined the channel [10:53] mikeal has joined the channel [11:37] rictic has joined the channel [13:16] bry has joined the channel [13:32] DamZ has joined the channel [13:45] pjb3 has joined the channel [14:11] cloudhead has joined the channel [14:33] alex-desktop has joined the channel [14:39] eviltwin has joined the channel [15:59] r11t has joined the channel [16:11] kriszyp has joined the channel [16:11] grantmichaels has joined the channel [16:29] jed has joined the channel [17:13] felixge has joined the channel [17:29] eddanger has joined the channel [17:33] eviltwin has joined the channel [17:38] dnolen has joined the channel [18:03] okito has joined the channel [18:05] rictic has joined the channel [18:31] cloudhead has joined the channel [18:43] eddanger has joined the channel [18:55] davidsklar has joined the channel [19:22] davidsklar has joined the channel [19:35] r11t has joined the channel [19:43] gwoo has joined the channel [19:46] jamiew has joined the channel [19:59] technowe_ has joined the channel [20:10] jamiew_ has joined the channel [20:16] aho has joined the channel [20:18] Yuffster has joined the channel [20:20] teemow has joined the channel [20:24] eviltwin has joined the channel [20:27] technowe_ has joined the channel [20:30] gwoo has joined the channel [20:41] jed has joined the channel [20:47] hornbeck has joined the channel [20:56] jamiew has left the channel [21:08] ako has joined the channel [21:08] dnolen has joined the channel [21:12] hassox has joined the channel [21:12] hassox: Morning folks [21:13] hassox: jed: Thar? [21:13] jed: hassox: here, yo. [21:13] hassox: Hey dude [21:13] jed: hassox: "mornin'" [21:13] hassox: Just wanted to check if you got the API doc? [21:14] jed: jah, i did. [21:14] jed: i left you a comment on github. [21:14] jed: it's definitely the best way to grok chain. [21:15] hassox: Cool :) [21:15] hassox: So, after reading it do you have any q's? [21:16] jed: no, i think it's pretty clear. [21:17] hassox: :) awesome [21:17] jed: was thinking you could event make the "before" and "on" methods listenable events in their own right. [21:17] ryanmcgrath has joined the channel [21:17] jed: like beforeSendBody, etc. [21:17] hassox: So how can I improve it? ;) [21:17] hassox: Oh [21:17] hassox: That's tidy [21:18] jed: (i'm allergic to method proliferation.) [21:18] hassox: Can I ensure that those callbacks have run as listeners _before_ the original method? [21:18] jed: hrm, i guess it depends on your implementation. [21:19] jed: also, how do subsequent request "body" and "complete" events fit? [21:20] hassox: What do you mean? [21:20] jed: well, the request event is just the start. [21:21] jed: a request then might also have several body events and a final complete event. [21:21] hassox: Right [21:22] jed: i don't see how those are handled. [21:22] hassox: That is independant of the sebdHeader and sendBody calls on the response [21:22] hassox: They're not ;) [21:22] jed: ha, okay. [21:22] jed: seems like a good place to start. [21:23] hassox: So far I haven't seen any need to wrap those with callbacks [21:23] hassox: Do you have a need? [21:24] jed: well, if you're okay being tied just to node, i guess there's no need. [21:25] hassox: Do other server envs provide request response objects with these methods? [21:26] jed: it's part of the request object. [21:26] jed: but most envs aren't event oriented like node. [21:26] ryanmcgrath: Hey [21:26] ryanmcgrath: What's the deal with basic auth headers in Node these days? [21:26] jed: jsgi buffers the incoming body, as far as i can tell. [21:27] ryanmcgrath: I can't seem to get them at all. [21:27] ryanmcgrath: Running off trunk. [21:27] hassox: Jed ergh [21:27] ryanmcgrath: Like, I don't see them anywhere in the request. [21:27] hassox: jed: I think at this stage I'm pretty tied to the request and response object node privides [21:28] hassox: ryanmcgrath: What do you Maleah? [21:28] hassox: Mean [21:28] jed: hassox: in that case, you're good as far as i can tell. [21:28] ryanmcgrath: In the request object, it doesn't seem to be recording auth headers. [21:28] ryanmcgrath: ala username:pass@whatever.org [21:28] hassox: jed: Not sure what others provide to be able to offer support [21:29] jed: ryanmcgrath: you're checking for the Authorization header, right? [21:29] hassox: ryanmcgrath: Do you mean the ones you're writing to send to the client? [21:29] ryanmcgrath: No, the ones that are being sent to me, on the server. [21:29] ryanmcgrath: jed: I'm trying to find where that even is. In the request object, the closest I see is "host", which doesn't record it. [21:29] hassox: Like Jed: says? [21:30] jed: ryanmcgrath: you need to check for the Authorization header in request headers. [21:30] hassox: What does request.headers have? [21:30] jed: ryanmcgrath: note that most clients won't even send it unless they try and get a 401. [21:31] hassox: jed: So what to do to improve [21:31] hassox: I obviusly want community support on this so we can move forward without furthr splintering of effort [21:32] hassox: And start writing some reusable bits [21:32] ryanmcgrath: These are the headers I have to work with, it seems: http://gist.github.com/273782 [21:32] ryanmcgrath: Based on the url... [21:32] jed: hassox: well, let's talk after i get (fab)'s async up. [21:32] ryanmcgrath: http://ryan:lol@gowah.ryanmcgrath.org/testcreds [21:32] hassox: Fab is ur chaining thing? [21:33] jed: ryanmcgrath: clients convert urls like that into an Authorization header. [21:33] hassox: ryanmcgrath: Seems ur client is not sendingit [21:33] jed: ryanmcgrath: they don't actually send the url like that. [21:33] hassox: Try curl [21:33] jed: hassox: yeah. [21:33] jed: similar thing. [21:33] hassox: jed: Id love it if we could use the same system obviously [21:33] ryanmcgrath: Hmm [21:34] ryanmcgrath: So curl shows it, you're right... [21:34] jed: ryanmcgrath: that format is losing support. [21:34] ryanmcgrath: Guess I've gotta change my approach, in this case, because the client I have sending to the server is... iffy, apparently. [21:34] hassox: Since if we all use different systems our stuff isn't going to interoperate [21:34] jed: ryanmcgrath: some browsers don't even allow it anymore. [21:34] ryanmcgrath: Good to know. [21:35] jed: ryanmcgrath: i think IE discontinued support for that format because it was being used for phishing. [21:35] jed: http://google.com:password@evilserver.com/ [21:36] jed: hassox: yeah, i'd love a common standard too. i guess you're not in love with JSGI? [21:37] hassox: There's a number of issues I have withit [21:37] hassox: It's nice that you can do sync or asynchronous [21:37] hassox: Which is also a problem IMHO [21:38] hassox: Also, the buffering of the request on every request doesn't fit node [21:38] hassox: I see node as a fresh start, where we have an opportunity to do something awesome [21:38] jed: hassox: i agree with a lot of that. [21:39] jed: (fab) will be async only. [21:39] hassox: I think that the base way of striving things together sgould play to the strengths node offers, without the compromise of callstack based arrangemnts [21:40] hassox: Strining [21:41] hassox: Sorry on the phone, bit hard to type [21:41] jed: i'm allowing sync responses (return x), but (fab) converts then into async. [21:41] jed: sure. [21:41] jed: i need to run too, let's chat later. [21:41] jed has left the channel [21:51] maritz1 has joined the channel [21:52] maritz1: if i have a function that calls an async function and needs to return something from the result of the async function, is that possible? if so, how? [21:56] mediacoder: maritz1: return a promise and emit a promise event in the async function [21:58] maritz1: yeah... I just can't wrap my mind around how I'll do it in my special case. But I'll find a way :D [22:02] mediacoder: hehe, allright :-) [22:03] felixge: sup folks? [22:03] felixge: :) [22:04] mediacoder: moin [22:05] hassox has joined the channel [22:09] _Ray_ has joined the channel [22:10] _Ray_: Hey, has anyone encountered problems with posix.read regarding spaces being converted to NULLs when in "binary" encoding? [22:11] _Ray_: Actually, the other way around - NULLs being converted to spaces. [22:16] inimino: _Ray_: got a testcase? [22:16] _Ray_: I'll make one. [22:22] _Ray_: inimino, http://pastebin.com/d723e6679 , with folder.gif from http://www.ibiblio.org/icons/folder.gif in the appropriate location. [22:22] jamiew has joined the channel [22:23] _Ray_: I hexdump -C both the folder.gif it's reading, and the folder.gif it sends, and every "00" becomes a "20". [22:25] _Ray_: Same happens with posix.cat. [22:25] inimino: hm [22:27] inimino: _Ray_: you need to specify the encoding on request.sendBody() [22:27] inimino: _Ray_: the default is "ascii", you want "binary" [22:27] _Ray_: Ohh, never knew about that [22:27] _Ray_: ACTION tries [22:28] inimino: _Ray_: also, read() is not guaranteed to read all the bytes in one go [22:28] _Ray_: Yeah, I should make is streaming, but I was just wondering why the dumb-as-a-rock case was failing :) [22:28] _Ray_: It works :) Thanks! [22:29] inimino: _Ray_: might I recommend my hot-of-the-press FileIO module: http://boshi.inimino.org/3box/fileIO/fileIO_cps.js [22:29] inimino: np :-) [22:29] _Ray_: Second time today I see Haskell comments on JS source. [22:30] inimino: ha, really! [22:30] inimino: what was the first? [22:31] _Ray_: Some guy was implementing "acid4", filled with ECMAScript tests [22:31] inimino: ah [22:31] _Ray_: http://fedelebron.com/acid4/index.xhtml [22:31] rtomayko has joined the channel [22:32] inimino: ah, cool [22:32] inimino: hehe, IO (Maybe Error) [22:32] _Ray_: I should type my exams that way... [22:33] inimino: I have avoided monadic types so far as I figure anything I use I'm going to have to explain :-) [22:33] inimino: http://boshi.inimino.org/3box/fileIO/README -- work in progress [22:34] isaacs has joined the channel [22:35] _Ray_: Hrm. Interesting. You're adding lazyness [22:36] _Ray_: I'll play with it a bit. Seems nice :) [22:36] isaacs: ryanmcgrath: ping [22:37] ryanmcgrath: Eh? [22:37] isaacs: hey, just saw your user:pass@host stuff in the logs [22:37] isaacs: you get that sorted? [22:37] ryanmcgrath: For the most part. [22:37] inimino: _Ray_: cool, let me know what you think [22:37] isaacs: the request doesn't get a raw user:host [22:37] isaacs: er, user:pass [22:37] isaacs: it gets an Authorization: header, which is base64 encoded. [22:37] isaacs: not for encryption, just to ensure that no invalid chars are sent over the wire. [22:37] ryanmcgrath: Mmmhmm [22:37] isaacs: sniff for that header, decode, and you're good. [22:38] isaacs: i meant to add a require("url").parseRequest(req) function that would handle stuffs like that [22:38] isaacs: haven't gotten to it yet [22:38] inimino: or it gets nothing, as mentioned above [22:38] isaacs: inimino: i must have missed that [22:38] isaacs: whenever i send user@host.com, it seems to send the Authorization header. [22:39] inimino: isaacs: someone said that IE8 has removed support for this, and I expect other browsers will too [22:39] isaacs: well that's lame. [22:39] aho: did someone write something bigger already? like blogging software, a forum, or a shop thingy? (minimalistic implementations thereof, that is) [22:40] inimino: it's fundamentally insecure and should be avoided even when it still works [22:40] isaacs: how are you supposed to send credentials to a url, then? [22:40] inimino: bbiab [22:40] inimino: isaacs: you're not [22:40] isaacs: inimino: sure, but we do this all over the place. [22:40] isaacs: i mean, all kinds of apis use that [22:41] inimino: isaacs: authorization doesn't belong to the resource and putting it in the URL is broken [22:41] inimino: then they're broken :-) [22:41] inimino: anyway, you can get precisely the same level of security by just putting a token in the URI [22:41] isaacs: inimino: sure, but it's not really about getting a level of security, it's about continuing to be able to use the twitter api [22:42] isaacs: even from curl, you should do -u "blah" -p "bloo" instead, of courese. [22:42] eviltwin has joined the channel [22:42] inimino: which works everywhere [22:42] inimino: well, browsers will break backwards compatibility for security reasons, and popular APIs will of course upgrade [22:43] inimino: ACTION really going afk now [22:50] scudco has joined the channel [22:54] bryanl has joined the channel [23:04] _Ray_: Hrm. Would it be too much of an "eeeeewww" to execute `file -i {file}` to get the mimetype of files to do a directory listing? (A la mod_mime, only made out of cardboard and ducttape) [23:15] inimino: _Ray_: if it's just for a directory listing you can probably use the extensions, if that's what the server uses when it serves them [23:15] inimino: (which most do) [23:16] _Ray_: Hrm. I thought Apache used the first few bits of the files [23:16] _Ray_: Ah, no, it has a list of extensions. [23:17] _Ray_: ACTION steals. Thanks :) [23:24] binary42 has joined the channel [23:26] mikeal has joined the channel [23:40] gwoo_ has joined the channel