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 <[email protected]> wrote: >> On Thu, Aug 19, 2010 at 21:27, Benoit Chesneau <[email protected]> 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
