Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of adam.kocoloski@gmail.com
 designates 209.85.218.52 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Futon Test Suite
From: Adam Kocoloski <kocolosk@apache.org>
In-Reply-To: 
 <CAJ_m3YDWzwtGheoV3C0ETFbh1Bx5-H-3iH27jcfJ-hspNcLKZw@mail.gmail.com>
Date: Mon, 15 Aug 2011 17:05:21 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <535FB000-980B-49DC-A44A-F0ACBC74033E@apache.org>
References: 
 <CAJ_m3YDr_G34C5SK=61hbkNWCP52=F46odGHn7wam7eU3cBktQ@mail.gmail.com>
 <CAL3q7H7PzRibp84usbU2ybSY5UOeFH+e8fVT8C+N3ZE3SFT9kg@mail.gmail.com>
 <CAJ_m3YBm6fu1EP8fZ9do8gj0kqgph04oR1-0_k1spMg4kF=-HA@mail.gmail.com>
 <CAJ_m3YBUOmZoGG1TTpiSum+83pFpsoiS670OBtjGoP4ofAeC3w@mail.gmail.com>
 <CAL3q7H5XS1e61dkUxY8thDy-L7FZgCbfNkwsAFqGAV2kD7xpug@mail.gmail.com>
 <CABvT1DF2CFfFppi=pmoNh7ynQ1marq-dZzQ5BEoWRikKja4mUQ@mail.gmail.com>
 <CAN-3CBKofp0EwGCtQAmYpwfQEfGcz90pHtG-LQLsqQMYTfzCOA@mail.gmail.com>
 <CAJ_m3YBQP1vn9=gdaSsfQWDdOYP-TKYf_=DMsEqC=fQ7+qLQCw@mail.gmail.com>
 <CAN-3CBK4_oFxLVHOSXrJE_rQnc_ywbC8jdn-o76QYX41uWqydg@mail.gmail.com>
 <CAJ_m3YAME3uBtxrbnLoTV0zCKydGnjbnk7bAtJAXn8b7Ti51WQ@mail.gmail.com>
 <CAN-3CBJu_=_7Gj1ytb-SBAUuN+c0-VRFMdScnBAbkRUWs+NOug@mail.gmail.com>
 <CAJ_m3YBySGFUNfb9-NKZnwmO1b9R7rSsKt0cq5PSwPLhrJsR6w@mail.gmail.com>
 <0E1FA99D-744A-4501-BBF9-5F29CB9D7F12@dionne-associates.com>
 <CAJ_m3YCp=JbXAL3+6sC9vkPe1MEhtO0nOvU_GNd4QxkY7P79WA@mail.gmail.com>
 <FACD18C1-8229-4BFB-
 9E98-570D7B0FDF7A@apache.org>
 <CAJ_m3YDWzwtGheoV3C0ETFbh1Bx5-H-3iH27jcfJ-hspNcLKZw@mail.gmail.com>
To: dev@couchdb.apache.org

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.
>=20
> [1] https://github.com/ry/http-parser
>=20
> On Mon, Aug 15, 2011 at 8:38 AM, Adam Kocoloski <kocolosk@apache.org> =
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.
>>=20
>> Adam
>>=20
>> On Aug 14, 2011, at 12:55 PM, Paul Davis wrote:
>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> On Sun, Aug 14, 2011 at 7:50 AM, Robert Dionne
>>> <dionne@dionne-associates.com> wrote:
>>>> Paul,
>>>>=20
>>>>  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).
>>>>=20
>>>>   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.
>>>>=20
>>>>   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.
>>>>=20
>>>>  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.
>>>>=20
>>>>   All that said, I have a few hours today to hack on this today if =
you want some help just ping me on #couchdb
>>>>=20
>>>> Bob
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> On Aug 12, 2011, at 11:46 AM, Paul Davis wrote:
>>>>=20
>>>>> 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.
>>>>>=20
>>>>> https://gist.github.com/1142306
>>>>=20
>>>>=20
>>=20
>>=20