couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
Date Thu, 19 Aug 2010 21:02:40 GMT
On Thu, Aug 19, 2010 at 4:21 PM, Jason Smith <> wrote:
> On Fri, Aug 20, 2010 at 01:43, Paul Davis <>wrote:
>> > CouchDB adoption is growing. The network, system, and programming
>> > responsibilities are becoming different people. It needs to allow
>> everybody
>> > to do their job.
>> >
>> Can you describe this in more detail? I don't think I understand your
>> concerns very well. I'm not familiar with hosting setups so maybe I'm
>> just missing something obvious. I just can't figure out  why a network
>> administrator would need to reverse engineer the vhost settings.
> Obviously I think a lot about CouchDB deployments where the couchapp
> developer is neither the sysadmin responsible for running the couchdb
> program, nor the network admin responsible for moving the bytes around. For
> example, I wrote the config whitelist feature because the, let's say, DBA
> should not have the ability to change the couchdb listen address or port in
> some operational situations.
> In a common reverse-proxy situation, you get a request and you look at the
> Host header and *maybe* the path and you decide where to route that query
> to.
> Well now with DBAs having a big old time with vhosts, the reverse proxy
> needs to know what vhosts have been configured so when it encounteres "Host:
>" it can say, "Oh right, was vhosted in
> Bob's CouchDB server, so I will route it there."
> The only way I think, let's call it the "CouchDB hosting community" knows
> how to do that is to query _config/vhosts for all the couches and populate
> the routing tables with those results.
> So I am not rejecting Benoit's idea, just saying that it will add burden to
> people who maintain reverse proxies in front of CouchDB.

Still confused. A couchapp developer shouldn't require any sort of
configuration because that's not under their control. For a couchapp
to be couchappy, its going to be barred from *requiring* such
configuration or it'll never work on the wide number of clients that
would be expected to host them as Chris points out.

As to the network admin side of things I'm confused why they would
ever trust routing tables to something they had no control over. I'd
think that they'd either treat them as the port and address settings
as specified by operations, or they'd just ignore them and route based
on OOB information.

For my curiosity, what happens when a vhost setting is wrong? Ie, Bob
set a vhost to be which should really go to Gene's
couch? Or when there's no vhost set at all? Or when a request comes
into a vhost that's unknown?

>> As to the bike shedding on syntax I can only say that the non-regexp
>> syntax looked fine to me. Though I understand the complaint about
>> inventing syntax, instead of jumping for regexp's I would probably
>> take a look at WebMachine's dispatcher mechanism as it reuses Erlang
>> which I always found quite nifty.
>> And a side point on the regexp syntax you posted:
>>    (.*).(.*).mydomain.tld -> /$2/_design/$1/_rewrite
>> This is a pretty good example of why regexps really aren't such a hot
>> idea. I'll give 10 internets to the first person that figures out how
>> that pattern matches this domain:
> I did simplify it for rhetorical purposes. I knew the dots didn't match
> themselves but I usually try to get away with the "greedy" matching before
> falling back to un-greedy.
> Of course, a hypothetical regex implementation would use Erlang's re module
> which is reasonably bug-free. As a sysadmin that gives me comfort. And when
> I discover a bug in my regular expression, there are countless resources.
> On the other hand, I am identifying the frustration that programmers and
> sysadmins get when they encounter an obviously new and unknown syntax.
> In other words: the principle of least surprise. CouchDB is HTTP for that
> reason. CouchDB is REST for that reason. View indexes are the same as
> databases for that reason. Applications are also documents for that reason.
> Replication is just another client for that reason.
> (However in an offline email I made it clear that I will happily defer to
> the implementation which exists!)
> And because its always funny:
>> Some people, when confronted with a problem, think
>> “I know, I'll use regular expressions.”   Now they have two problems.
>> - Jamie Zawinski
> Very droll. But the point is given too much credit due to its clever
> presentation. My first day at Couchio I heard Mikeal say, "the problem with
> domain-specific languages is now everybody thinks he's a fucking language
> designer."
> --
> Jason Smith
> Couchio Hosting

View raw message