couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <...@couch.io>
Subject Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
Date Thu, 19 Aug 2010 20:21:27 GMT
On Fri, Aug 20, 2010 at 01:43, Paul Davis <paul.joseph.davis@gmail.com>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:
blog.example.com" it can say, "Oh right, blog.example.com 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.


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message