Return-Path: Delivered-To: apmail-incubator-couchdb-dev-archive@locus.apache.org Received: (qmail 25882 invoked from network); 4 Dec 2008 18:46:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Dec 2008 18:46:24 -0000 Received: (qmail 17812 invoked by uid 500); 4 Dec 2008 18:46:35 -0000 Delivered-To: apmail-incubator-couchdb-dev-archive@incubator.apache.org Received: (qmail 17784 invoked by uid 500); 4 Dec 2008 18:46:35 -0000 Mailing-List: contact couchdb-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: couchdb-dev@incubator.apache.org Delivered-To: mailing list couchdb-dev@incubator.apache.org Received: (qmail 17773 invoked by uid 99); 4 Dec 2008 18:46:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Dec 2008 10:46:35 -0800 X-ASF-Spam-Status: No, hits=3.4 required=10.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [64.233.170.186] (HELO rn-out-0910.google.com) (64.233.170.186) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Dec 2008 18:45:06 +0000 Received: by rn-out-0910.google.com with SMTP id k50so4126248rnd.3 for ; Thu, 04 Dec 2008 10:45:42 -0800 (PST) Received: by 10.90.70.15 with SMTP id s15mr8147829aga.82.1228416342005; Thu, 04 Dec 2008 10:45:42 -0800 (PST) Received: by 10.90.56.8 with HTTP; Thu, 4 Dec 2008 10:45:41 -0800 (PST) Message-ID: <64a10fff0812041045t6a5d9f40p1a17fdf9a376691c@mail.gmail.com> Date: Thu, 4 Dec 2008 13:45:41 -0500 From: "Dean Landolt" To: couchdb-dev@incubator.apache.org Subject: Re: API suggestions In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_144044_24746627.1228416342005" References: <214c385b0812040401r4f90146bw17a8526018fe4c98@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_144044_24746627.1228416342005 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline > > Following on from "Document Bits", would it be sensible to reserve > > *all* path segments beginning with an underscore for CouchDB's use? > > > > This is worth at least thinking about. Having the _attachments path > would open the door to an attachments index view, as well as > attachments with literal '/' in the name. > > What do people think of the _attachment path as a way out of the %2F > dilemma? Seems like a logical way out of the dilemma, and as Matt pointed out it leaves more room for extension points. Plus, I remember some discussion about rewrite rules on the roadmap -- those that think _attachments is too ugly for their app would eventually be able to rewrite them away. ------=_Part_144044_24746627.1228416342005--