couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
Date Thu, 19 Aug 2010 17:13:13 GMT
On Thu, Aug 19, 2010 at 7:00 PM, Jason Smith <jhs@couch.io> wrote:
> On Thu, Aug 19, 2010 at 22:23, Benoit Chesneau <bchesneau@gmail.com> wrote:
>
>> To answer in a more generic way. As a "sys admin" or "operatives", you
>> are already habit to vhosts or Locations with http servers. This is
>> the same system here. Nothing new, just a syntax different.
>>
>> I think also there is 2 views of couchdb in oposition here. One is
>> about managing couchdb in multi mass hosting other is to see couchdb
>> as a standalone db that could be used on any device.
>>
>
> Back around 0.9, there was a huge discussion about "transactional" bulk
> inserts.
>
> The prevailing view was that CouchDB does not show a behavior unless it can
> show that behavior in all possible deployments.
>
> I am asking if the same logic applies here.
>
> In the future when every device has CouchDB and every ISP runs it and every
> carrier caches it and everything, apps need to work there too. That is why I
> am attracted to a simple vhost implementation.
>
>
>> This feature isn't yet implemented. It only works for domain names.
>> You don't need to use a wildcard. If you're worried about your users
>> and the fact they could use this feature, I am thinking this is just
>> an operative concern. If you don't want that your user set vhosts like
>> this then you will have to think to a way to do this. I'm not sure
>> that couchdb should concern about it, especially since you can
>> whitelist _config. You could also create your own _config handler that
>> filter entries .
>>
>
> Since I wrote the whitelist feature, yes I am aware how I could work around
> supporting this.
>
> I have operational concerns. However I am simply asking that the community
> think very hard about what this means before permanently committing to it.
>
> Specifically, the fact is CouchDB is a fantastic platform with very, very
> few good applications. CouchDB is years ahead of the popular couchapps with
> respect to polish and features.
>
> My point is, are we bending CouchDB in order to cover for the fact that
> there is no good App Admin tool out there?
>
> Maybe the answer is no. Okay, fine, as long as the decision is deliberated
> and understood by everybody, cool! I do agree about two things:
>
>  1. It is difficult for beginners to develop on localhost:5984 and then push
> to couch.domain.tld. vhost is managed separate from the ddoc and even the
> DB, so it does not replicate. It totally sucks.

>  2. It is hard to manage vhosts. You have cURL and you have Futon, which did
> not even work correctly in 1.0.0.
>
> It would bother me if I do not know which "Host" header to reply to without
> inspecting all database and ddocs.

>
> My preference is dumb vhosts and a smart rewriter. For example, if the
> rewrite rule could see the req object and Host header, it could redirect to
> the correct db, ddoc, and path.
>

A couchapp should be  "domain" independant, this is the principle of a
couchapp . So I can replicate anywhere and not only in
centralizedhost.com . Following this principle, it sound weird to set
an hostname in the CouchApp.

About difficulty to handle couchapp behoind a vhost or not, it's
already handled by current system :

You can set a rewrite rule to always use the database or detected if
you were rewritten by comparing req.requested_path vs req.path.

Mime
View raw message