couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Chris Anderson <jch...@apache.org>
Subject Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
Date Thu, 19 Aug 2010 19:28:40 GMT
I'll admit I'm a little lost here too. What is the change to $foo supposed to allow for, and
what is the downside to having it?

I think the example:

$app.$db.example.com = /$db/_design/$app/_rewrite

is actually pretty compelling *as a convenience feature.*

However, Jason is arguing that the convenience is putting some smarts in a place that would
be better off dumb. This is the same argument that the Google/Verizon stuff is about: should
the middleware part of the stack be smart or dumb? So far, dumb has been the clear winner
in the general case, even when it is a pain in the specific case. We should reflect on that
before we jump to making this change.

My top concern with all of this vhost stuff is much more basic, and I think needs to be addressed
before we think about adding convenience features:

On localhost, there is no such thing as a Domain Name (unless you are the type to hack your
/etc/hosts, which is like 0.01% of people).

KEY POINT: Any CouchApp which is designed to require vhosts is automatically not capable of
running on localhost.

Until we solve this issue I'm not much interested in refining the existing vhost stuff.

Chris

On Aug 19, 2010, at 11:43 AM, Paul Davis wrote:

> On Thu, Aug 19, 2010 at 10:59 AM, Jason Smith <jhs@couch.io> wrote:
>> On Thu, Aug 19, 2010 at 21:27, Benoit Chesneau <bchesneau@gmail.com> wrote:
>> 
>>> Could you explain me how it's impossible compared to previous
>>> behaviour ? It doesn't change anything technically. Please post all
>>> your concern and a way to reproduce , I will have a look on it. Though
>>> here hosting > 50 couch - trunk behingd couchdbproxy works. tested
>>> yesterday.
>>> 
>> 
>> ## The top priority question:
>> 
>> How can proxies managed by the sysadmin or network admin know what to do?
>> 
>> Now, vhost is explicit. Anybody with permission can query /_config/vhosts
>> for all couches.
>> 
>> With wildcards, e.g. "*/blog", it is impossible to know all domains which
>> the web server handles. When a query for  fooapp.foodb.mydomain.tld arrives,
>> which couch should handle it?
>> 
>> 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.
> 
> 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:
> 
>    blog.davisp.mydomain.tld
> 
> One hint is that it wouldn't rewrite to /davisp/_design/blog/_rewrite.
> 
> 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
> 
> 
> HTH,
> Paul Davis


Mime
View raw message