couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
Date Thu, 19 Aug 2010 16:48:37 GMT
On Thu, Aug 19, 2010 at 6:30 PM, Jason Smith <> wrote:
> On Thu, Aug 19, 2010 at 23:14, Benoit Chesneau <> wrote:
>> On Thu, Aug 19, 2010 at 5:56 PM, Noah Slater <> wrote:
>> >
>> > On 19 Aug 2010, at 16:49, Benoit Chesneau wrote:
>> >
>> >> Well asking without giving yourself some data make it irrelevant but
>> >
>> > Not really.
>> >
>> > I'm suggesting that if we're going to use performance as an argument, we
>> use data and not supposition.
>> The way pattern matching works should explain by itself though ;)
> AFAIK Erlang ships with Perl-compatible regular expressions written in C.
> re:compile()
Yes. so ?

> Anyway the whole performance argument is not relevant. Who cares? You are
> about to do a b-tree lookup from the hard disk. How much will regex vs.
> pattern match on a 20-byte string matter?

b-tree ? Where ?
> My point was, why are we inventing syntax out of our asses for every
> different situation? Regular expressions should be considered because:
>  1. They match patterns

yes. Pattern matching too but we only match terms,  and they are
common in Erlang.

>  2. They capture groups and can access them later

yes. who care ? A lot of urls rewriters are not using regexp because
it adds an extra layer of complexity: webmachine in erlang, werzeug in
python, ...

>  3. Everybody knows them

that's not true.

To answer to this "reinventing" . We had long discussions on how to
manage rewriting in couchapps. Some included "regexp", we fall in the
current system. Ie pattern matching because it was a lot easier to
understand and *simple*.  SInce the system is already in place, I
wanted to reuse it too, there is no need to have 2 dofferent ways to
handle rewriting.

I would like to keep it *simple*, that's the key.

Anyway, can we go back to the topic ? I still don't understand how
vhosts in 1.0.1 or in trunk are a problem ? About that I'm thinking we
could propse a request_handler that isn't relying to vhost at all and
make them an option, would it be ok ?

View raw message