Ah, you'd just embed the http-parser itself, reducing dependencies instead of trading one for another. +1,
Adam On Aug 15, 2011, at 10:41 AM, Paul Davis wrote: > Not sure I follow what you mean there. When I mentioned node's HTTP > parser, I meant, the parser [1]. I'd still have to write my own C > adaptor for that to Spidermonkey objects. Not entirely certain on the > REPL bit, but couchjs was basically a hack on top of the Spidermonkey > js REPL so going back to our roots a bit there shouldn't be too hard. > > [1] https://github.com/ry/http-parser > > On Mon, Aug 15, 2011 at 8:38 AM, Adam Kocoloski <[email protected]> wrote: >> I thought about suggesting node's parser, especially since you'd get the >> REPL for free. I think the downside is that there are roughly 300 versions >> of node out there, and I'd hate for our tests to keep breaking because of >> node's development pace. libcurl is nothing if not stable. >> >> Adam >> >> On Aug 14, 2011, at 12:55 PM, Paul Davis wrote: >> >>> My plan was to rewrite couch.js to use the new request/response >>> classes internally and then when we need closer HTTP access we'd be >>> able to have it. Same for T and Tequals. and what not. There is at >>> least one test that we just can't make work in our current couchjs >>> based test runner because it needs to use async HTTP requests, so at a >>> certain point we have to at least add some of this stuff. >>> >>> I quite like using etap over eunit as it seems more better. Also, now >>> that we're going to a second language for make check tests, it seems >>> like an even better approach. Though I'm not at all married to it by >>> any means. Also, I do understand your concerns about moving parts and >>> uncessesary dependencies. I should get around to updating the build >>> system to use the single file etap distribution but its never really >>> been a concern. >>> >>> Another thing I've been contemplating is if it'd be beneficial to >>> remove libcurl and replace it with node.js's parser or with the ragel >>> parser from Mongrel. Anyway, food for thought. I'll be around this >>> afternoon to hack. >>> >>> On Sun, Aug 14, 2011 at 7:50 AM, Robert Dionne >>> <[email protected]> wrote: >>>> Paul, >>>> >>>> This is interesting, and if you're willing to put together the new >>>> infrastructure I can help with writing tests. I would suggest a more >>>> incremental approach that's less of a rewrite (rewrites often just get you >>>> back to 0 from a user's perspective). >>>> >>>> The existing CouchDB JS object seems to work ok in terms of the http >>>> interface, and the Futon tests more or less all ran using couchjs until >>>> very recently. I would suggest getting these all running first, reusing >>>> copies of the existing CouchDB objects and such so we can hack them as >>>> needed. Then we would review and throw out all the tests that are not part >>>> of the core APIs, like the coffee stuff (I don't know why we decided to >>>> bundle coffee in there) and any tests that are for specific internals. >>>> >>>> At some point something like BigCouch is integrated in or MobileCouch we >>>> might have different "make" targets for the different deployments. Perhaps >>>> in that case we'd have different sets of tests. There needs to be a set of >>>> tests that can verify that the semantics of API calls is the same in >>>> CouchDB and BigCouch. >>>> >>>> So I'd say let's work backwards from what we have. Also I'm not a big fan >>>> of etap, preferring eunit mainly because it's one less moving part. For JS >>>> we already have this T(...) and TEquals(....) funs which seem to do the >>>> trick. >>>> >>>> All that said, I have a few hours today to hack on this today if you >>>> want some help just ping me on #couchdb >>>> >>>> Bob >>>> >>>> >>>> >>>> >>>> On Aug 12, 2011, at 11:46 AM, Paul Davis wrote: >>>> >>>>> Here's a bit of a brain dump on the sort of environment I'd like to >>>>> see our CLI JS tests have. If anyone has any thoughts I'd like to hear >>>>> them. Otherwise I'll start hacking on this at some point over the >>>>> weekend. >>>>> >>>>> https://gist.github.com/1142306 >>>> >>>> >> >>
