[1:30]<nrstott> deanlandolt, I got cookie middleware working basically! [1:31]<nrstott> do you think it should be used yb default in exports.Client as your Redirect is? [1:31]<nrstott> this is the gist if you're curious: http://gist.github.com/520196 [2:48]<deanlandolt> nrstott: i think it should be used anywhere redirect is (so yeah, in Client) [2:49]<nrstott> deanlandolt, sent you a pull request about an hour ago [2:49]<deanlandolt> but only if there's a logical /store/ associated with it [2:49]<nrstott> it's basically working, still needs a bit of polishing [2:49]<deanlandolt> (meaning, caching could be defaulted too) [2:49]<deanlandolt> sorry, been away from the computer [2:49]<nrstott> it does not take into account expirations and path currently [2:49]<nrstott> it does domains [2:50]<deanlandolt> doing domains is really the only important part... [2:50]<nrstott> well, we should do the others, i just needed something for my proxy middleware now ;0 [2:50]<deanlandolt> technically...lacking expirations is a memory leak [2:50]<nrstott> im proxying couchdb and needed login to work [2:50]<deanlandolt> ahh, well sweet [2:52]<nrstott> let me know if you see any probs with the approach [2:52]<nrstott> i did not put it on the 'this' of request as we'd talked about as the middleware approach and keeping it in the closure seemed to make more sense [2:56]<deanlandolt> the thing that first jumps out at me is would you like a utility that split "request.url" into its requsite components? that should probably the first bit of middleware i suppose [2:57]<deanlandolt> also, is there a guarantee (based on the dozen or so cookie rfcs...i can't even keep track) that the keys are case sensitive? [2:59]<deanlandolt> e.g. is there a difference between HttpOnly and httponly? i remember playing that game with certain user agents back in the day and it didn't matter [2:59]<deanlandolt> if it's the case that it doesnt matter we'd have to pull the HashP code from narwhal into promised-io [3:01]<deanlandolt> also, req.headers["Cookie"] should be req.headers["cookie"] ...all headers are lowercase in this context (the interface is /technically/ jsgi...and it has some implications if you were to throw caching around the cookiejar) [3:02]<deanlandolt> nrstott: in any event, this looks awesome...very useful [3:02]<nrstott> ah ok [3:02]<nrstott> i didnt realize about the all lowercase [3:03]<nrstott> im not sure if there is a guarnatee that the cookies are case-snesitive [3:03]<deanlandolt> yeah...that's what the HashP thing's all about in jack...but after quite a bit of discussion 0.3 does away w/ variable case [3:03]<nrstott> maybe we should be using something like narwhals HashP [3:03]<nrstott> yeah i defintiely need to fix the request.url part :) [3:03]<nrstott> ill do that real quick, now that i have the querystring module riped from jack that should be easy [3:04]<deanlandolt> well, that's actually irrelevant for the content of a header (cookies.Version, cookies.HttpOnly, etc) [3:04]<deanlandolt> the case only matters for headers themselves (cookie and set-cookie) [3:04]<deanlandolt> (though you have set-cookie all lowercase already) [3:05]<nrstott> well, HttpOnly, Version, and Path are coming back in the case that i put them there [3:05]<nrstott> i noted the set-cookie was lowercase [3:05]<nrstott> wasn't sure why [3:05]<deanlandolt> i'm just not positive what the rfcs say about what comes in the url-encoded payloads...if there are any promises about case [3:05]<nrstott> but now you explained that [3:06]<nrstott> well acutally i need a url module to rip... [3:06]<nrstott> like the one i proposed on the commonjs mailing list ;0 [3:07]<nrstott> id realy like to see JSGI 0.3 go to more browser-based naming conventions [3:07]<deanlandolt> yeah, that's a fair comment [3:07]<deanlandolt> (sorry, just got back from vacation but read that) [3:07]<deanlandolt> i've got an update to the 0.3 spec ready to publish [3:07]<nrstott> does Jack have a url parser? [3:07]<nrstott> i can't seem to locate it [3:08]<deanlandolt> not that i know of, no [3:08]<deanlandolt> as far as jack's concerned the url comes in parsed [3:08]<deanlandolt> but one belongs there (and tom has suggested he'd be thrilled to have such nicities in the jack codebase) [3:08]<nrstott> well somehwere something parses it [3:09]<nrstott> any idea where that something is [3:09]<deanlandolt> point me to where it gets parsed and i'll track it down [3:09]<deanlandolt> the cookie code perhaps? [3:10]<deanlandolt> generally what comes in for jack is an actual request...the whole "url" thing is a promised-io/http-client specific nicicty [3:10]<deanlandolt> nicity [3:10]<deanlandolt> it's to bypass having to provide a whole req environemnt [3:10]<nrstott> it doesn't look like there's node specific stuff in node's URL module [3:10]<nrstott> we could just use that [3:10]<deanlandolt> sure enough [3:11]<deanlandolt> what are you looking to break apart though? in this case i'd think we're trying to parse a url into a jsgi request [3:11]<nrstott> well there is require("path") [3:11]<nrstott> well that's what im looking to do [3:11]<nrstott> so that i can paly nice with the 'url' convention of http-client [3:11]<nrstott> need to get the domain out of it [3:11]<deanlandolt> okay, well that's probably pretty straitforward with regex [3:11]<nrstott> need to get the path too realy for future [3:12]<nrstott> sure, but a URL module woudl be oh so much nicer :) [3:12]<deanlandolt> there's no way to go to scriptName/pathInfo from a plain url, but that just means there's no scriptName and it's all pathInfo [3:12]<nrstott> you can go to pathInfo can't you? That's just the path after the domain [3:13]<deanlandolt> yeah, i agree...but it's not really something we can bring in a package for [3:13]<deanlandolt> yeah...you can even snoop for fragment if you want to be real cute [3:13]<nrstott> im not proposing that we add a dependency, im proposing just abducting the node url module [3:13]<nrstott> as i abducted the jack queyrstring module [3:13]<deanlandolt> sure... [3:14]<deanlandolt> just saying, does it really do what we're asking [3:14]<nrstott> absolutely [3:14]<nrstott> we'd just have to translate (or make small alterantions) [3:14]<deanlandolt> sure... [3:14]<nrstott> in fact the engine/node code already uses it for this very purpose [3:15]<deanlandolt> i'll take a peak...but i'm doubtful they respect anything but an http(s) url :-/ [3:15]<nrstott> http://github.com/ry/node/blob/master/lib/url.js [3:15]<deanlandolt> after scheme it's pretty much every man for himself...and in the context of http client that's fine.. [3:16]<deanlandolt> that's an /insane/ amount of code! [3:16]<nrstott> i know... that's why i dont want to redo it if its that difficult :) [3:16]<deanlandolt> that's an isaacs job, i betcha :D [3:16]<nrstott> it is [3:16]<nrstott> is he notorious for long code or something? [3:17]<deanlandolt> well, not long for the sake of being long [3:17]<deanlandolt> but long for usually good reasons [3:17]<deanlandolt> i'm just not sure what they are here [3:17]<nrstott> i think its that its not really that simple to parse a url ;0 [3:17]<deanlandolt> heh...he's got /gopher/ in there [3:17]<nrstott> yeh [3:17]<deanlandolt> it's impossible to parse a strait url [3:18]<deanlandolt> because it's rfc-dependent [3:18]<deanlandolt> you can only parse a scheme [3:18]<nrstott> right [3:18]<nrstott> looks like the difficulty in urlParse fn is in handling partial URLs and handling file vs http [3:19]<nrstott> or 'hostlessProtocol' vs 'slashedProtocol' as he terms it [3:19]<deanlandolt> long story short this isn't actually doing anyone any favors [3:19]<nrstott> oh? [3:19]<deanlandolt> you can't handle a relative url in this context so that's all bs [3:19]<deanlandolt> either it's there or its not [3:20]<nrstott> well sure, in our case [3:20]<deanlandolt> too much magic going on here (and i'm sure he'd agree :)) [3:20]<nrstott> the writer of the magic usually doesn't agree that there's too much of it :) [3:20]<deanlandolt> that's not true w/ isaacs [3:20]<nrstott> then why did he write it like this [3:21]<nrstott> to plesae the masses or something? [3:21]<deanlandolt> because he didn't have time to write it more concisely [3:21]<deanlandolt> or was smart enough not to try [3:21]<nrstott> ok how about this [3:21]<nrstott> http://blog.stevenlevithan.com/archives/parseuri [3:22]<deanlandolt> but none the less, i've gone back and forth with him about this kind of stuff and he'd typically bitch about just this kind of thing [3:23]<deanlandolt> nrstott: that code looks surprisingly solid [3:23]<nrstott> yeah it looks awesome [3:23]<nrstott> the test suite is fancy too [3:23]<nrstott> going to module this up [3:23]<deanlandolt> it does the mailto: proto :) [3:24]<nrstott> ? [3:24]<deanlandolt> try it [3:24]<deanlandolt> in the demo [3:24]<nrstott> oooh [3:24]<deanlandolt> it parses authority [3:24]<nrstott> yeh [3:24]<deanlandolt> it fails elegantly is all i'm saying [3:25]<deanlandolt> the protocol is blank (as it should be) [3:25]<deanlandolt> but if you do a mailto://foo@bar.com it gets it all [3:26]<deanlandolt> but mailto:foo@bar.com is successful enough to be, well, successful [3:27]<nrstott> yeh this code rocks [3:29]<nrstott> think im about to have the url shortcut working [3:32]<deanlandolt> awesome...that's spectacular...it just sucks that it's now another module that's locked in another package :-/ [3:32]<deanlandolt> dependencies are still /broken/ in commonjs [3:33]<nrstott> what language are they not broken in? [3:34]<deanlandolt> heh [3:34]<deanlandolt> i'd say javascript [3:35]<nrstott> deanlandolt, just pushed my changes [3:35]<deanlandolt> <script.../> ... that's a pretty awesome dep management [3:35]<deanlandolt> nrstott: i'll pull now [3:39]<deanlandolt> nrstott: there's a require("./querystring") but lib/querystring.js didn't come in w/ my merge [3:39]<deanlandolt> did you commit that? [3:40]<nrstott> probably not, let me do that [3:40]<nrstott> ok its in [3:40]<deanlandolt> sweet, thanks [3:40]<nrstott> deanlandolt, do you develop nodules any? [3:40]<deanlandolt> now all we need is /tests/ :D [3:41]<deanlandolt> no, that's about the only one of kris's projects i haven't dug into at all [3:41]<nrstott> ive got an issue when i map to local file system packages the require("./whatever") in those packages doesn't work [3:41]<deanlandolt> but i've poked at the source a bit [3:42]<nrstott> when mapping to github URLs, the packages work fine though [3:42]<deanlandolt> hmm, yeah that sounds like the kind of thing that could be a bug [3:43]<deanlandolt> overriding require is dangerous in that kind of way :-/ [3:43]<nrstott> yeh i guess i should stop being lazy and look into nodules [3:43]<deanlandolt> i run almost everything on rhino so i don't use it that often...when i do i've been fortunate enough for it to Just Work [3:44]<nrstott> I have been running on node recently [3:44]<nrstott> was just using npm for everything until i started using transporter [3:45]<deanlandolt> have npm and nodules played well together? [3:53]<nrstott> kind of [3:53]<nrstott> i packaged nodules for npm ;0 [3:53]<nrstott> so now i just do 'npm install nodules' then i use nodules for everything else [10:54]<Dantman> Ack... the dumps haven't been running all this time [10:55]<Dantman> I screwed up the cd path in the cron job