couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Burobjorn <>
Subject Re: Seeking advice on using couchdb for rewritting a project.
Date Thu, 13 Nov 2008 10:30:40 GMT
Hi Chris,

> 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.

I really like the idea, although I also see lots of issues surrounding
this approach.

- For instance is it possble to decide which documents should be
replicated and which not? I can imagine people not wanting to replicate
certain more private data to other hosts (such as passwords...).

- Another issue would be the upload and download of attachments. We
strive to let people upload only lossless formats such as wav, flac and
aiff. However we want to make downloads available in lossy formats as
well.Therefor we need to be able to process the audio so we can offer
the lossy formats as well. This seems impossible to do without some
commandline magic and the usage of applications like SOX. This would
probably be hard to do on each localhost.

There's probably lots more to think about. For now it might be good idea
for us to start writing things down and do some development ;)

We've created a bazaar repository on Launchpad and setup a mailinglist
there as well.


There is not much there yet, but feel free to join us if you're interested.

> 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.

Mhhm this might solve some of the previous mentioned issues. I need some
more time to experiment with couchdb and see what we can do to
facilitate this.

> 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.

Now I remember where I heard your name before!

I'm also on the XSPF list and we've been using XSPF for Simuze since the
beginning. We're most definately going to use XSPF both as an internal
format as well as an external feed for collections such as an album or

All the best,


View raw message