incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Futon Test Suite
Date Thu, 11 Aug 2011 16:46:15 GMT
On Thu, Aug 11, 2011 at 5:57 AM, Jason Smith <jhs@iriscouch.com> wrote:
> On Thu, Aug 11, 2011 at 4:29 PM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
>> All very good except this one paragraph. The CouchDB definitely should
>> not be expected to run with an intermediary server. If an intermediary
>> is broken, its quite all right that we engineer paths around
>> brokenness, but that's secondary by many orders of magnitude to
>> asserting the behavior of CouchDB's API.
>
> I buy that.
>
> What about if and when the test suite splits into "confirm the
> install" vs. a comprehensive unit tester? I suppose the comprehensive
> test can demand a direct (or even null?) connection. But can "confirm
> the install" be so bossy?
>
> I guess the answer is also "yes." You are confirming end-to-end
> (browser-to-server) functionality. If the proxy is breaking
> expectations, then indeed you *want* to see a big red warning.
>
> The only problem is this:
>
> CouchDB developers are sitting pretty in the United States, maybe
> Western Europe: basically the center of the universe. Everything is
> fast, packets never drop, latency is an afterthought. Meanwhile,
> across Latin America, Russia, China, and South and Southeast Asia
> (that I know of, from support tickets), EDGE networking is everywhere.
> Packets always drop. Non-standard transparent proxies are everywhere.
> They are built in to ISPs. You cannot avoid them. Unlike the West,
> HTTPS is not magic. There is huge latency, the handshakes take many
> seconds to complete.
>
> On stardate 47805.1, Commander Benjamin Sisko famously said:
>> On Earth, there is no poverty, no crime, no war. You look out the
>> window of Starfleet Headquarters and you see paradise. Well, it's
>> easy to be a saint in paradise, but the Maquis do not live in paradise.
>> Out there in the Demilitarized Zone, all the problems haven't been
>> solved yet. Out there, there are no saints — just people. Angry, scared,
>> determined people who are going to do whatever it takes to survive,
>> whether it meets with Federation approval or not!
>
> It is easy to be a saint in paradise. This applies to CouchDB and
> Couch apps. On many ISPs, the non-standard, "transparent" proxies are
> inescapable. But yet, web applications always work. The LA Times
> works, news.google works, random wordpress blogs work, everything I've
> ever clicked from Hacker News works. But yet Couch apps are joke. It
> seems nothing is ever cached when it should be, and everything is
> always cached when it shouldn't be. Authentication, in particular,
> fails because caching proxies don't care about DELETE /_session.
>
> I have no immediately actionable advice here, but my goal is just to
> point out that, at some point, demanding standards-compliance becomes
> bigotry, and if we are too ideologically pure, we risk alienating a
> larger development community. And read those list of countries again.
> These communities stand to gain the most from CouchDB and the p2p web.
>
> --
> Iris Couch
>

Your points are definitely well taken, and these are the sorts of
things we should be engineering for and around. But I'll bring the arc
back to CouchDB. Our test suite has the specific purpose of asserting
that CouchDB behaves the way we want. Intermediaries only serve to
confound the results of these tests, "Did CouchDB fail? Or is it
something in the middle?" which doesn't do anyone any good.

On the other hand, I'm all for dealing with intermediaries by making
adjustments to our various API's (and then including tests in the test
suite to assert the different behavior). And even adding pieces to the
Futon installation verification to check deep dark corners of bad
proxy behavior. Or even having an extended set of "proxy tests". But
these sorts of tests aren't testing CouchDB, they're testing how HTTP
proxies traverse bad intermediaries.

I'm know this might be a subtle point, but I think its quite important
to make the distinction. The Apache CouchDB Test Suite (proper noun)
should be all about testing Apache CouchDB as possible. Specifically,
it shouldn't be testing things that are not Apache CouchDB. Like
broken proxies. On the other hand an "Apache CouchDB Client Access
Test Suite" that checks for all sorts of broken user agents and
intermediaries would be an excellent addition to our tests.

Mime
View raw message