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 >>> >>> > >
