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 level > 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 would > 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 > http://www.freedesktop.org/wiki/Specifications/desktopcouch > > -- > - eric casteleijn > https://launchpad.net/~thisfred > http://www.canonical.com >
