Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of kxepal@gmail.com designates
 209.85.212.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <529DFA3E.3010706@gmail.com>
References: <529DE44C.4090400@bigbluehat.com>
	<529DFA3E.3010706@gmail.com>
Date: Tue, 3 Dec 2013 22:11:57 +0400
Message-ID: 
 <CAHdjipJ0J_8zj2z3y1DbfbGHHVhx4LVGGF2AGkQkC+t5NGPQPw@mail.gmail.com>
Subject: Re: [PROPOSAL] new underscore namespacing
From: Alexander Shorin <kxepal@gmail.com>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=f46d043be23c663ce504eca53bdc

--f46d043be23c663ce504eca53bdc
Content-Type: text/plain; charset=UTF-8

+1 for meta. It's cool idea and every doc has some meta info like type field

-1 on /_/ url thing.  It's ugly and not related to reserved namespace: you
may define any named handler in config file and having _ prefix saves you
from collision with atts (but it's still optiona)
On Dec 3, 2013 7:37 PM, "Volker Mische" <volker.mische@gmail.com> wrote:

> On 12/03/2013 03:01 PM, Benjamin Young wrote:
> > Hi all,
> >
> > Recently the "doc._*" reservation has been causing me trouble when
> > pulling in "arbitrary" JSON from various sources that also use the
> > underscore prefixed names for things (HAL [1], vnd.error [2], other
> > APIs). I've also hit the wall several times when trying to import
> > filesystem contents (Sphinx, ghpages, and the like) that use _*
> > prefixing for their "special folders."
> >
> > As such, I'd like to propose the following:
> > 1. Begin storing new reserved terms in doc._.* (rather than doc._*).
> >  - this gives developers one object to look into for the meta-data about
> > a doc
> >  - you can see the scope creep of our current doc._* best in the
> > replicator status messages.
> >     - doc._ replication_* would become doc._.replication.*
> > 2. Move "magic" API endpoints under "/_/" term as well (for the sake of
> > attachments.
> >  - _design/doc would stay the same
> >  - but the child endpoints would live under "_design/doc/_/*"
> >     - _design/doc/_/view/by_date
> >     - _design/doc/_/list/by_date/ul
> >     - _design/doc/_/rewrite
> >
> > I realize these are extreme API shifts, and would need to wait for
> > CouchDB 2.0.
> >
> > The first steps this direction would be to put new reserved word keys
> > into a "doc._.*" namespace going forward. Closer to the "cut over" for
> > 2.0 duplicates of the existing keys (doc._id, doc._rev, especially)
> > could also live at their new underscore prefixed names (doc._.id,
> > doc._.rev) which would give devs a chance to migrate code and content.
> >
> > Doing this would:
> > 1. Give us "limitless" space to add content.
> > 2. Encourage a namespacing pattern for things like doc._.replication.*
> > or other logically grouped content.
> > 3. Free up CouchDB to accept a far broader range of content and remove
> > the "hey, you can't put that there! I was here first!" errors. :)
> >
> > Thanks for considering this,
> > Benjamin
> >
> > [1] http://stateless.co/hal_specification.html
> > [2] https://github.com/blongden/vnd.error
>
> Hi,
>
> I personally would prefer to have the meta information completely
> separate from the document. I know there have been discussion in the
> past to even have them separate in the backend (but that's not the point
> of this proposal).
>
> So the API for the view function could change to `function(doc, meta)`.
> This way you could store in your document whatever you like.
>
> Cheers,
>   Volker
>
>
>
>

--f46d043be23c663ce504eca53bdc--