Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jwalgran@gmail.com designates
 209.85.219.215 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:reply-to:in-reply-to:references:date:message-id
         :subject:from:to:content-type:content-transfer-encoding;
        b=s5NxtESo/bOyeHhQvd4bABmGgFtNVYU7lqBvfuu6BjPVGOechSTvtnosdI+4AV2nfg
         VPh2ouNej/T/Ee9aU6cgiEsE1tB0MALkCK2SDmUnHqGMOIZiWnYcKaHxUBgyH2LdmHo6
         Jie+HNoJZtC2oaX41ofj/8e9lJ56QPFJt+xy8=
MIME-Version: 1.0
Reply-To: jwalgran@gmail.com
In-Reply-To: <4A7C3EA6.6070704@canonical.com>
References: <f893e2810908061547o730ceed7ma571878ee8772adb@mail.gmail.com>
	 <4A7C3EA6.6070704@canonical.com>
Date: Fri, 7 Aug 2009 11:04:50 -0400
Message-ID: <f893e2810908070804o4fe59c4dn8dde4103e779eb80@mail.gmail.com>
Subject: Re: Best practice: adding an app specific chunk to a document
From: Justin Walgran <jwalgran@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Eric, that is exactly the type of thing I was looking to support in my app.

Are other app developers using the convention of storing app specific
data under a "doc.application_annotations.[namespace]" key?

It seems like agreeing to a standard is a good way to go. That said,
if I had a database of job applicant documents, then the key
"application_annotations" will likely collide with the actual data.
How would you handle this situation in desktopcouch?

-Justin

> We've decided to have things that all applications agree on as a top leve=
l
> field in the document, described by a schema (so a contact would have
> first_name and last_name, and some other fields that every application wo=
uld
> conceaivably be interested in) and then there is a dictionary called
> 'application_annotations' where each application has its own namespace in
> which it can store application specific data, or data that not all
> applications agree on.
>
> This is a flexible way to do things in that it doesn't impose a lot on
> applications that work with it (you don't *have* to look at
> application_annotations if you don't need it, all we ask is that you don'=
t
> delete it) and it makes complicated use cases possible.
>
> [1] https://code.launchpad.net/desktopcouch
> =A0 =A0http://www.freedesktop.org/wiki/Specifications/desktopcouch
>
> --
> - eric casteleijn
> https://launchpad.net/~thisfred
> http://www.canonical.com
>