On Thu, Aug 19, 2010 at 7:00 PM, Jason Smith <[email protected]> wrote: > On Thu, Aug 19, 2010 at 22:23, Benoit Chesneau <[email protected]> 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.
