couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson" <>
Subject Re: Seeking advice on using couchdb for rewritting a project.
Date Wed, 12 Nov 2008 17:01:42 GMT
On Tue, Nov 11, 2008 at 10:02 AM, Burobjorn <> wrote:
> Our objective is to rewrite Simuze in such a way that we can distribute
> it as an 'easy' to install webapplication under a free/open-source
> license (Affero GPL). We would like to connect all the different Simuze
> installs (replication would be very helpful for this, I guess) and
> create a distributed free (as in CC licensed and PD) music web. Think of
> it as a non-suck MySpace built by musicians ;)

I really like this idea. I've built applications like this a few times
( and and generally have been hoping
someone would do this with CouchDB. Jan's already covered how Couch
can handle the queries you need. I also think CouchDB is a good fit
for what you are going for.

There are some architectural option Couch makes available that are so
different from the standard monolithic SQL approach, that they are
worth considering.

1) Lots of databases. If you give each user their own database, you
open up the power of replication even more. For instance, users could
run the application on their laptop when adding / editing song
metadata, and then replicate to (their own database) on a public
CouchDB instance, for backup and to publish their music collection.
Other users / hosts could be allowed to replicate that database to
their own CouchDB instances, either for offline use or to create their
own compliations, etc. If the value proposition of the software is
tied to being able to bring it to localhost, then you probably won't
even need to Affero GPL to keep people from running with competing
"hosted" versions of the site.

2) Lots of apps. Eg the publishing application can be maintained in a
separate design document from the browsing application. As long as
they both know how to read the documents, there's no need for them to
have interdependencies. I think this loose-coupling (while it might
entail a little code duplication) can make open-source easier to
manage from a development perspective. If you get an enthusiastic
contributor who does a major rewrite of the playlist composing and
sharing side of the app, their changes can be distributed
independently of the slower-moving upload and metadata management side
of things.

Back in my playlist days, I helped draft a JSON version of XSPF
( We call it JSPF (JSON Shareable Playlist Format),
the draft is available here:

JSPF is extensible, and somewhat of a standard, so I'd encourage you
to use it as your CouchDB music metadata format if it fits. I've also
been looking for a good opportunity to open source aspects of the front end, which is basically an Ajax playlist micro-blogging
application based on JSPF. I'd be happy to send some of that code your
way. Although lots of it is probably throw-away, there are bits that
could be useful to your project.

Excited to see what you come up with!


Chris Anderson

View raw message