On 12.11.2008, at 19:26, "Dean Landolt" <[EMAIL PROTECTED]> wrote:
On Wed, Nov 12, 2008 at 12:55 PM, Paul Davis <[EMAIL PROTECTED]
>wrote:
On Wed, Nov 12, 2008 at 12:44 PM, tasman <[EMAIL PROTECTED]>
wrote:
On Nov 11, 2008, at 8:02 PM, Burobjorn wrote:
Hi everybody,
My name is Bjorn Wijers and I recently started to play with
couchdb.
It's a very interesting project and I would like to use it to
rewrite an
older project called Simuze[1], but I wonder if couchdb would be
the
right tool for the job. Perhaps some of you can help me out in
understanding the pro's and con's of using couchdb for this?
Simuze is musicplatform (website) for musicians and music fans by
non-profit Stichting (=Foundation) Open Media. Artists can upload
their
music under a Creative Commons license of their choosing and music
lovers can download these songs from the site. It was built quite
some
time ago in PHP and MySQL.
The basics in this application are:
- users
- profiles (might be multiple per user, since a user may have
more than
one artist persona)
- media files (images and audio for now)
- media collections (such as a playlist or album)
- ratings (every media file or collection)
- tags (everything)
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 ;)
Some questions that I have are:
1) Would this type of application be suitable for couchdb or is
this
better suited by using a RDBMS?
It depends more on "queries", that you will need.
2) Could we use the attachment feature for adding media files
(FLAC or
WAV or AIFF files roughly 50 MB per file) to couchdb? Or is this
not
advisable given the size of the files? The reasoning behind this
is that
by using replication we can easily backup the whole system or
setup an
another node of it. Therefor having everything in one place seems
like a
good idea?
Saving big attachments into CouchDB sounds like not good idea, i
think.
AFAIK your binary attachments store into CouchDB in base64
encoding, so
their size increase. And replication mechanism isn't too fast yet.
Please correct me, if it's wrong.
This used to be correct. Attachments no longer have to be base64
encoded when using the standalone attachments API.
One thing I've wondered about was streaming? At some point I want to
dump in
my mp3 collection and write a simple _external app with a flash
music player
that could play songs on the fly. My guess is it would work fine with
chunked responses, but what about jumping ahead past a buffered point?
Jumping doesn't work yet. Can you open a JIRA feature request for the
skipping? I might give it a shot.
Cheers
Jan
--
