Mochabot log - CommonJS IRC channel: #commonjs on irc.freenode.net

2010-07-27:

[0:47] <paulbaumgart> can anyone recommend an xpath query package? something pure-js preferably.
[20:35] <nrstott> kriszyp, I'm about to convert to using nodules. The mappings are becoming more and more important to me.
[20:37] <kriszyp> heh, good to hear you joining the good guys, nrstott :)
[20:37] <nrstott> I'm also converting my couchdb lib to use promises...
[20:37] <nrstott> however, I'm a little frustrated that it seems like this promises.js that you wrote is just copied into multiple projects, promsied-io and node-jsgi
[20:37] <nrstott> should this not be in its own module?
[20:38] <nrstott> I am about to copy it into yet another package... seems like this will get out ofhand
[20:42] <kriszyp> yeah, I know what you mean, nrstott, sometimes I am not sure where a module should live...
[20:43] <kriszyp> I am treating it's main home for my purposes as being in promised-io, that's where I also reference it
[20:43] <kriszyp> but I wanted jsgi-node and nodules to be able to work without any dependencies so they are copied there
[20:43] <kriszyp> esp nodules, obviously nodules can't have deps, since it handles the deps :)
[20:43] <nrstott> kriszyp, that makes sense that it would be in promised-io and if promised-io included an interoperable http-client I could even use it as a base t obuild my couchdb module off of
[20:44] <kriszyp> oh, I think deanlandolt1 has an update that should fix http-client to be completely interoperable
[20:44] <kriszyp> I'll pull...
[20:44] <kriszyp> cuz he was working on a couch module for perstore...
[20:45] <deanlandolt1> yeah...still don't have binary support in there and rhino-http-client isn't actually returning a promise yet
[20:45] <nrstott> kriszyp, there's one other prob iwth http-client in promised-io for my purposes... it creates a new XHR for every request.
[20:45] <nrstott> I would realy like to have a http client that reused the same xhr again and again so that i could pull-off the 'reqeust queue' technique
[20:45] <deanlandolt1> but go ahead and pull kriszyp -- it works nicely...i'll let you know when i have more fixes in
[20:45] <nrstott> that's how ive started writing my couchdb module couchdb-commonjs
[20:45] <kriszyp> you mean in the browser?
[20:46] <kriszyp> you are using this on server and client?
[20:46] <nrstott> yes
[20:46] <nrstott> both
[20:46] <kriszyp> you are cool
[20:46] <kriszyp> :)
[20:46] <deanlandolt1> heh :D
[20:46] <deanlandolt1> kriszyp: oh, and before you pull -- should the shortcut for url be url or uri?
[20:46] <nrstott> i have a node wrapper for XHR... i mstarting to use yabble so i can use modules client side
[20:46] <nrstott> i had been kinda hacking it before ;0
[20:46] <deanlandolt1> node had url and rhino and default had uri IIRC
[20:46] <nrstott> i had been throwing all stuff into one 'module', but thanks to yabble and transporter i will no longer have to do that
[20:47] <kriszyp> url?
[20:47] <kriszyp> yabble works better for you than requirejs?
[20:47] <deanlandolt1> kriszyp: you know, the shortcut for scheme/host/pathInfo/queryString
[20:47] <kriszyp> yeah, I know what you are talking about deanlandolt1
[20:47] <deanlandolt1> so it should be url? then pull and fix i guess :D
[20:48] <deanlandolt1> or give me a minute
[20:48] <kriszyp> btw, I checked in a 50 line browser module receiver for transporter that is an alt to yabble and requirejs
[20:49] <kriszyp> Probably minifies to about 1 or 2 KB, I bet
[20:49] <nrstott> cool
[20:49] <nrstott> im not a big fan of requirejs... but yabble is suiting my needs so far. how doe syours differ from yabble
[20:49] <kriszyp> mine can't proactively load anything, it can only receive
[20:50] <kriszyp> which works well if you are using a script tag and using transporter dep resolver, so it doesn't have to proactively load anything
[20:50] <deanlandolt1> oh, nrstott: also, the new http-client code has a Client obj that you can set up to follow redirects and whatnot
[20:50] <nrstott> deanlandolt1, what s most important to me is that if I do client.request(...) then another client.request(...) that the reqeusts are 'queued' so they happen sync
[20:51] <nrstott> if i want them to happen async i want to make 2 clients
[20:51] <deanlandolt1> since you're using both in browser and node you may want to look at expanding that to make the behaviors match even more (cookie jar and caching)
[20:51] <nrstott> sync as in one after another (the requests), not as in blocking
[20:51] <deanlandolt1> you mean client.request(...).then(client.request(...))?
[20:51] <nrstott> no
[20:51] <nrstott> i mean client.request; client.request
[20:51] <kriszyp> of courses patches are welcome nrstott :)
[20:51] <nrstott> i want the first request to complet ebefore the 2nd request finishes
[20:51] <deanlandolt1> oh? well, that's not how async works, sadly :-/
[20:51] <nrstott> deanlandolt1, not really... :)
[20:52] <nrstott> if you use the same XHR and a request queue, its still "async" but its deterministic order
[20:52] <deanlandolt1> ah, i see
[20:52] <nrstott> it makes code -much- easier to follow
[20:52] <deanlandolt1> but that's still a cheat..
[20:52] <nrstott> hows it a cheat?
[20:52] <deanlandolt1> because you can't really count on node to do that
[20:52] <deanlandolt1> in fact, you definitely can't
[20:52] <nrstott> sure i can, ive got an XHR wrapper for node :)
[20:53] <nrstott> it uses a single client behind the scenes
[20:53] <nrstott> a single httpClient
[20:53] <deanlandolt1> you still have to do response.then(client.request...)
[20:53] <deanlandolt1> in that case you'll have to patch promised-io/engines/node/http-client.js to use XHR
[20:53] <nrstott> http://github.com/nrstott/couchdb-commonjs/blob/master/lib/couchdb.js#L47
[20:54] <nrstott> that's how im doing it now... i am obviously looking to make this soilution cleaner now that i can use require in the browser as well to seperate things out into modules
[20:54] <nrstott> but the approach is shown in my _queueRequest method
[20:54] <deanlandolt1> it's still a cheat :)
[20:54] <nrstott> I think that is the reasonable appraoch in node and in browser. in node if you use a single httpClient you get the behavior im speaking of as well
[20:55] <nrstott> you can "queue" your requests
[20:55] <nrstott> hehe, is it a cheat? or is it a good abstraction? :)
[20:55] <nrstott> do you not like it? i think it's a nice technique
[20:55] <deanlandolt1> a cheat...async http requests should be able to happen in parallel -- if you want to specify the control flow you should use an abstraction explicitly for that purpose
[20:56] <deanlandolt1> it's not that i don't like it...i agree, it'd make things easier :D
[20:56] <nrstott> what sense does it make for a single httpClient to be able to have multiple open requests? :)
[20:56] <deanlandolt1> but you're counting on tacit behavior that's not really guaranteed by anything
[20:57] <nrstott> maybe the http-client in promised-io should just be extensible so that I could make it have this behavior easily enough but not have it be the default behavior
[20:57] <deanlandolt1> it could block your program
[20:57] <deanlandolt1> when perhaps you just need a response from one
[20:57] <deanlandolt1> or you could act on the result of the third or forth request
[20:57] <deanlandolt1> it already is...
[20:58] <deanlandolt1> you just have to do .then (or promise.when)
[21:01] <nrstott> we'll just have to agree to disagree on this one i guess ;0 writing my program with promises or callbacks nested layers and layers deep doesn't appeal to me. I could write an abstraction ontop of the httpClient i suppose... a "request queue" that would do what I wanted and use composition to accomplish the goal
[21:01] <nrstott> requestQueue.queue(...) and have it handle it behind the scenes with the promises
[21:03] <deanlandolt1> yeah, that's probably the Right Thing
[21:04] <deanlandolt1> i don't disagree that these deeply nested layers are a little hairy, but counting on implicit, unspecified behavior is even more hairy :D
[21:04] <nrstott> all behavior is specified via the contract you make with your users via the interface
[21:05] <nrstott> calling that unspecified is akin to calling any other behavior, including promises themselves, unspecified
[21:05] <nrstott> but I'll explore the request queue option
[21:05] <deanlandolt1> assuming an http client won't make requests in parallel is what i mean by depending on unspecified behavior
[21:05] <deanlandolt1> after all, that's what asyncronous code does with i/o...that's the point
[21:06] <nrstott> why would you assume an http clinet _would_ make requests in paralell? :) in any other language, you would assume it wouldn't
[21:06] <deanlandolt1> if you have a bunch of requests queued up (say you're just a proxy) and one of them hangs for a few minutes...you're s.o.l.
[21:06] <deanlandolt1> any other language? i wouldn't assume twisted's http client queues requests ;)
[21:07] <nrstott> if i were a proxy, id use multiple clients :)
[21:07] <nrstott> ok well you got me there. idont usually think twisted and python though
[21:07] <deanlandolt1> :D
[21:07] <deanlandolt1> oh well, i hear you...
[21:07] <nrstott> or eventmachine and ruby
[21:07] <deanlandolt1> just throwing in my two cents
[21:07] <nrstott> yeah ill go with the request queue approach
[21:07] <nrstott> itll prbably be cleaner anywa
[21:08] <nrstott> my goal is to have my couchdb client queue its requests behind the scenes and if you want to do multiples in parlell you make multiple clinets
[21:08] <deanlandolt1> nrstott: if you look at my http-client code you could probably write a piece of middleware that does just that
[21:09] <nrstott> middelware as in JSGI middleware?
[21:09] <deanlandolt1> call it QueuedClient and you're in business
[21:09] <deanlandolt1> heh...yeah, promised-io/http-client uses the jsgi interface :D
[21:09] <nrstott> oh. i hadn't even considered using middleware with the jsgi-client
[21:09] <nrstott> neat concept :)
[21:09] <deanlandolt1> http://github.com/deanlandolt/promised-io/blob/master/lib/http-client.js#L57
[21:10] <nrstott> deanlandolt1, very cool
[21:10] <deanlandolt1> try that with an event-based interface!
[21:10] <deanlandolt1> composition is awesome
[21:11] <deanlandolt1> oh yeah, and i need to make the response for the browser and rhino versions a lazy-array like kris did with the node version...
[21:11] <deanlandolt1> so then you get all the awesomeness of array extras on your response.body object
[21:12] <deanlandolt1> map/reduce/filter/etc
[21:15] <deanlandolt1> kriszyp: just pushed the uri->url change
[21:15] <kriszyp> ok, all synced
[21:15] <kriszyp> thank you
[21:41] <deanlandolt1> kriszyp: does promise.wait work on node?
[21:41] <kriszyp> I don't think so
[21:41] <deanlandolt1> hmm...oh well...i'm adding request.jsgi.async=false support and i dont think node provides async http, does it?
[21:41] <kriszyp> I thought the loop/unloop mechanism was no longer available to do that
[21:42] <deanlandolt1> oh well...no request.jsgi.async=false for node :D
[21:42] <kriszyp> you mean node doesn't provide sync http support?
[21:42] <deanlandolt1> i didn't think so
[21:42] <deanlandolt1> just sync fs
[21:42] <kriszyp> right
[21:42] <kriszyp> that's why nodules has to do static analysis before loading anything

 

 

Logs by date :