Proposed desktopcouch changes
Eric Casteleijn
we (some of the desktopcouch developers) are currently sprinting in
Orlando, and aside from adding documentation, fixing bugs and general
cleanup, we have a few items that we'd like wider feedback on, since
we're thinking of some fundamental changes. Please tell us what you
think, or ask questions where things are unclear. Also join us in the
#desktopcouch channel on freenode, if you're so inclined.
Our guiding principle will be: DON'T BREAK EXISTING API. Where we make
API changes, we will try to deprecate old methods and provide new ones.
In the case of data model changes, we will try to make the new code
tolerant of the previous format, and/or provide semi-automatci data
migration.
* Mergeable lists will no longer be the default.
When assigning a list to a field in desktopcouch, the default behavior
will be to store it as a normal JSON list, instead of what we do now,
which is convert it to a MergeableList object first, and storing it as a
uuid keyed dictionary in CouchDB.
Support for mergeable lists will not be deprecated, but if you want to
use them, you'll have to explicity create a MergeableList object and
assign that to the field.
Also we propose that if an item is removed from a mergeable list,
desktopcouch will make an effort to remove any references to it in
application annotations. (We will define how to reference items in
mergeable lists from application annotations, and only remove references
that conform to this specification.)
* Instead of adding a 'deleted' flag to documents, they will be moved to
a 'trash' database, where they can be recovered from, or permanently
deleted, if so desired. This means the views and a lot of code will no
longer have to filter out deleted documents, but application developers
are still able to provide the same limited undo capabilities they could
now. (Documents will be moved to u1_trash/[original db name]-[original
document id] to prevent id clashes.)
* We would like to expose the continuous _changes feed in our API, and
we'll likely do some initial experiments with this. If you have ideas on
how you would like to use it in your applications, feel free to butt in.
* Split desktopcouch in multiple packages, with a more friendly import
structure.
We'd like to split out the application (the part that starts up the
desktopcouch couchdb instance, takes care of automatic replication,
provides the port lookup functionality etc.) From the library code, that
other applications will want to import and use. We'd also like to give
each document type specification its own package, so that its easier to
see how to create one's own.
The Python namespacing we propose (the old import paths will continue to
work for now, but show deprecation warnings) would be something like:
library: desktopcouch.records (example imports: from
desktopcouch.records import Record, CouchDatabase)
application: desktopcouch.app (example from desktop.app import find_port)
document types: from desktopcouch.contacts import Contact
* Make the API more consistent.
This is a multifaceted item, but mainly we'd like to return the same
kinds of objects everywhere (so Records, or specific subclasses such as
Contacts,) and integrate better with python-couchdb: it has changed
quite a bit since we started using it, and we'll want to take advantage
of its newer features, contribute back things like OAuth, which are not
desktopcouch specific, and offer patches for things that we think can be
improved.
* (Re)connection to couchdb.
This is something we're redesigning currently, to be more robust so that
applications can trust that when they talk to desktopcouch, it will find
the user's couchdb instance, and start it if it's not already running.
This is not an easy problem, and any ideas are welcome. Expect a more
detailed outline of our plans in this regard soon, but feel free to
suggest your own ideas before hearing ours.
Also if there are things you would like fixed, changed or added in the
next six months, whether big or small, now would be a good time to raise
them.
--
eric casteleijn
https://code.launchpad.net/~thisfred
Canonical Ltd.
_______________________________________________
Mailing list: https://launchpad.net/~ubunet-discuss
Post to : ubunet-...@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubunet-discuss
More help : https://help.launchpad.net/ListHelp
Jonathan Lange
<eric.ca...@canonical.com> wrote:
...
> * Split desktopcouch in multiple packages, with a more friendly import
> structure.
>
> We'd like to split out the application (the part that starts up the
> desktopcouch couchdb instance, takes care of automatic replication, provides
> the port lookup functionality etc.) From the library code, that other
> applications will want to import and use. We'd also like to give each
> document type specification its own package, so that its easier to see how
> to create one's own.
>
Would this address bug 591039, "Cannot import desktopcouch in server
environment"?
jml
Eric Casteleijn
Yessir. I will add that bug to our list of targets for this cycle.
Jonathan Lange
<eric.ca...@canonical.com> wrote:
> On 11/03/2010 06:28 AM, Jonathan Lange wrote:
>>
>> Would this address bug 591039, "Cannot import desktopcouch in server
>> environment"?
>
> Yessir. I will add that bug to our list of targets for this cycle.
>
Awesomesauce. Thanks.
jml