You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Burobjorn <bu...@gmail.com> on 2008/11/11 19:02:15 UTC
Seeking advice on using couchdb for rewritting a project.
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?
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?
3) In a RDBMS such as MySQL I can use foreign keys to preserve data
integrity. In other words I can delete the user and due to the foreign
keys 'automatically' remove its profile(s), uploaded media etc. How
would one solve this with couchdb?
Thanks for reading this rather lengthy email. Looking forward to the
thoughts and comments on this.
All the best,
grtz
BjornW
[1] http://www.simuze.nl
--
met vriendelijke groet,
Bjorn Wijers
* b u r o b j o r n .nl *
digitaal vakmanschap | digital craftsmanship
Concordiastraat 68-126
3551 EM Utrecht
The Netherlands
phone: +31 6 49 74 78 70
http://www.burobjorn.nl
Re: Seeking advice on using couchdb for rewritting a project.
Posted by Burobjorn <bu...@gmail.com>.
Hi Jan,
Thanks for the quick and friendly response. We're going to test and see
how we can use couchdb. I'll probably be asking a lot more questions
than ;)
Just one minor comment: the phpillow library is AFAIK not mentioned on
the couchdb wiki. Perhaps its a good idea to mentioned it on this page:
http://wiki.apache.org/couchdb/Getting_started_with_PHP
All the best,
grtz
BjornW
> Hi Bjorn!
>
> On Nov 11, 2008, at 19:02, Burobjorn wrote:
>> 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.
>
> Personally, I think this is a cool app :)
>
>
>> 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 ;)
>
> So far, this sounds like a good use-case for CouchDB.
>
>
>> 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?
>
> I don't think an RDBMS has an advantage over CouchDB considering the
> data. Things might look a lot different from what you are used to, but it
> will all come together and be easier in the end.
>
>
>> 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?
>
> There is no limitation (ok, currently it is 4GB, but that is adjustable) on
> how big a a document attachment can be. Using replication for backup
> is a good idea.
>
>
>> 3) In a RDBMS such as MySQL I can use foreign keys to preserve data
>> integrity. In other words I can delete the user and due to the foreign
>> keys 'automatically' remove its profile(s), uploaded media etc. How
>> would one solve this with couchdb?
>
> With CouchDB you can only make "loose references" and CouchDB does
> not do cascading deletes. But a two-request process helps you there:
>
> 1) Get all docs for a certain property
> 2) Send a bulk delete request with the previous result
>
> Yes, this is not as convenient and there's a potential race condition, but
> this is easily solvable.
>
>
>> Thanks for reading this rather lengthy email. Looking forward to the
>> thoughts and comments on this.
>
> I'd say: Go for it.
>
> Feel free to send any follow-up question.
>
> Regarding PHP libraries to use, I'd recommend
> http://kore-nordmann.de/projects/phpillow/index.html
>
> Cheers
> Jan
> --
>
Re: Seeking advice on using couchdb for rewritting a project.
Posted by Jan Lehnardt <ja...@apache.org>.
Hi Bjorn!
On Nov 11, 2008, at 19:02, Burobjorn wrote:
> 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.
Personally, I think this is a cool app :)
> 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 ;)
So far, this sounds like a good use-case for CouchDB.
> 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?
I don't think an RDBMS has an advantage over CouchDB considering the
data. Things might look a lot different from what you are used to, but
it
will all come together and be easier in the end.
> 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?
There is no limitation (ok, currently it is 4GB, but that is
adjustable) on
how big a a document attachment can be. Using replication for backup
is a good idea.
> 3) In a RDBMS such as MySQL I can use foreign keys to preserve data
> integrity. In other words I can delete the user and due to the foreign
> keys 'automatically' remove its profile(s), uploaded media etc. How
> would one solve this with couchdb?
With CouchDB you can only make "loose references" and CouchDB does
not do cascading deletes. But a two-request process helps you there:
1) Get all docs for a certain property
2) Send a bulk delete request with the previous result
Yes, this is not as convenient and there's a potential race condition,
but
this is easily solvable.
> Thanks for reading this rather lengthy email. Looking forward to the
> thoughts and comments on this.
I'd say: Go for it.
Feel free to send any follow-up question.
Regarding PHP libraries to use, I'd recommend
http://kore-nordmann.de/projects/phpillow/index.html
Cheers
Jan
--
Re: Seeking advice on using couchdb for rewritting a project.
Posted by Chris Anderson <jc...@apache.org>.
On Thu, Nov 13, 2008 at 2:30 AM, Burobjorn <bu...@gmail.com> wrote:
> - 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...).
Right now the only granularity available is at the database level.
That said, keeping all your passwords in one database and your
shareable data in another is a fine approach. In the future, there are
plans to allow replication to be filtered by a view, but I'm not sure
what security guarantees this will present.
>
> - 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.
>
I'm interested in seeing how this shakes out, in general. I have a
feeling that we'll see some services continue to live in the cloud.
For instance, if enough people are in the position to use it, there's
probably money to be made by a generic audio transcoding service. Why
should we all have to hook up Amazon S3/SQS and LAME, when one good
working install should do the trick?
> 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.
>
Yes, the point of my email was to encourage you (and others) to think
outside the box regarding application architectures. CouchDB gives us
the opportunity to rewrite some of the rules. We've probably only just
scratched the surface of what's possible.
> Now I remember where I heard your name before!
>
Cheers!
Chris
--
Chris Anderson
http://jchris.mfdz.com
Re: Seeking advice on using couchdb for rewritting a project.
Posted by Burobjorn <bu...@gmail.com>.
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.
See:
https://launchpad.net/simuze
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
> (http://xspf.org). We call it JSPF (JSON Shareable Playlist Format),
> the draft is available here: http://wiki.xiph.org/index.php/JSPF_Draft
>
> 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
> Grabb.it 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
playlist.
All the best,
grtz
BjornW
Re: Seeking advice on using couchdb for rewritting a project.
Posted by Chris Anderson <jc...@apache.org>.
On Tue, Nov 11, 2008 at 10:02 AM, Burobjorn <bu...@gmail.com> 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
(http://grabb.it and http://mfdz.com) 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
(http://xspf.org). We call it JSPF (JSON Shareable Playlist Format),
the draft is available here: http://wiki.xiph.org/index.php/JSPF_Draft
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
Grabb.it 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
--
Chris Anderson
http://jchris.mfdz.com
Re: Seeking advice on using couchdb for rewritting a project.
Posted by Dean Landolt <de...@deanlandolt.com>.
On Wed, Nov 12, 2008 at 2:34 PM, Jan Lehnardt <ja...@prima.de> wrote:
>
>
> On 12.11.2008, at 19:26, "Dean Landolt" <de...@deanlandolt.com> wrote:
>
> On Wed, Nov 12, 2008 at 12:55 PM, Paul Davis <paul.joseph.davis@gmail.com
>> >wrote:
>>
>> On Wed, Nov 12, 2008 at 12:44 PM, tasman <ta...@gmail.com> 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.
I can open a JIRA for an arbitrary seek, which may be universally useful,
but it probably wouldn't work for things like variable bit rate mp3s, and I
doubt it would work for serving video (something couch is otherwise pretty
well suited for). I remember reading that for certain container formats of
video this is possible with a special index in the beginning of the file. Of
course, all of this would be way out of scope for couch to know about -- it
would probably make a great plugin though.
Re: Seeking advice on using couchdb for rewritting a project.
Posted by Jan Lehnardt <ja...@prima.de>.
On 12.11.2008, at 19:26, "Dean Landolt" <de...@deanlandolt.com> wrote:
> On Wed, Nov 12, 2008 at 12:55 PM, Paul Davis <paul.joseph.davis@gmail.com
> >wrote:
>
>> On Wed, Nov 12, 2008 at 12:44 PM, tasman <ta...@gmail.com>
>> 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
--
Re: Seeking advice on using couchdb for rewritting a project.
Posted by Jan Lehnardt <ja...@apache.org>.
On Nov 12, 2008, at 21:26 , Chris Anderson wrote:
> I believe this is the relevant spec:
>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35
>
> Range requests seems like an edge case, and then you turn out to need
> them. I'd advocate that we only provide this functionality for
> attachments. Making it work for regular JSON requests seems like pure
> folly.
Definitely attachments only.
Cheers
Jan
--
>
>
> Chris
>
> On Wed, Nov 12, 2008 at 11:36 AM, Bradford Winfrey
> <br...@yahoo.com> wrote:
>> Could something like a Partial Content headers (HTTP Code 206, I
>> believe) be used? I know this can be used to resume a download,
>> but I'm not sure if it could be used to "fast-forward" mp3's. I
>> guess if there's some sequence this wouldn't be possible, but I
>> just thought I'd throw it out into the brainstorm.
>>
>> Brad
>>
>>
>>
>>
>>
>> ________________________________
>> From: Dean Landolt <de...@deanlandolt.com>
>> To: couchdb-user@incubator.apache.org
>> Sent: Wednesday, November 12, 2008 1:26:21 PM
>> Subject: Re: Seeking advice on using couchdb for rewritting a
>> project.
>>
>> On Wed, Nov 12, 2008 at 12:55 PM, Paul Davis <paul.joseph.davis@gmail.com
>> >wrote:
>>
>>> On Wed, Nov 12, 2008 at 12:44 PM, tasman <ta...@gmail.com>
>>> 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?
>>
>>
>>
>>
>
>
>
> --
> Chris Anderson
> http://jchris.mfdz.com
>
Re: Seeking advice on using couchdb for rewritting a project.
Posted by Dean Landolt <de...@deanlandolt.com>.
On Wed, Nov 12, 2008 at 3:26 PM, Chris Anderson <jc...@apache.org> wrote:
> I believe this is the relevant spec:
>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35
>
> Range requests seems like an edge case, and then you turn out to need
> them. I'd advocate that we only provide this functionality for
> attachments. Making it work for regular JSON requests seems like pure
> folly.
Certainly. That seems like a pretty reasonable spec though, and now that I
think about it, it should be up to the client to handle any interpretation
of indexes to get the relevant range. I'll open up a JIRA.
Re: Seeking advice on using couchdb for rewritting a project.
Posted by Chris Anderson <jc...@apache.org>.
I believe this is the relevant spec:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35
Range requests seems like an edge case, and then you turn out to need
them. I'd advocate that we only provide this functionality for
attachments. Making it work for regular JSON requests seems like pure
folly.
Chris
On Wed, Nov 12, 2008 at 11:36 AM, Bradford Winfrey
<br...@yahoo.com> wrote:
> Could something like a Partial Content headers (HTTP Code 206, I believe) be used? I know this can be used to resume a download, but I'm not sure if it could be used to "fast-forward" mp3's. I guess if there's some sequence this wouldn't be possible, but I just thought I'd throw it out into the brainstorm.
>
> Brad
>
>
>
>
>
> ________________________________
> From: Dean Landolt <de...@deanlandolt.com>
> To: couchdb-user@incubator.apache.org
> Sent: Wednesday, November 12, 2008 1:26:21 PM
> Subject: Re: Seeking advice on using couchdb for rewritting a project.
>
> On Wed, Nov 12, 2008 at 12:55 PM, Paul Davis <pa...@gmail.com>wrote:
>
>> On Wed, Nov 12, 2008 at 12:44 PM, tasman <ta...@gmail.com> 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?
>
>
>
>
--
Chris Anderson
http://jchris.mfdz.com
Re: Seeking advice on using couchdb for rewritting a project.
Posted by Bradford Winfrey <br...@yahoo.com>.
Could something like a Partial Content headers (HTTP Code 206, I believe) be used? I know this can be used to resume a download, but I'm not sure if it could be used to "fast-forward" mp3's. I guess if there's some sequence this wouldn't be possible, but I just thought I'd throw it out into the brainstorm.
Brad
________________________________
From: Dean Landolt <de...@deanlandolt.com>
To: couchdb-user@incubator.apache.org
Sent: Wednesday, November 12, 2008 1:26:21 PM
Subject: Re: Seeking advice on using couchdb for rewritting a project.
On Wed, Nov 12, 2008 at 12:55 PM, Paul Davis <pa...@gmail.com>wrote:
> On Wed, Nov 12, 2008 at 12:44 PM, tasman <ta...@gmail.com> 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?
Re: Seeking advice on using couchdb for rewritting a project.
Posted by Dean Landolt <de...@deanlandolt.com>.
On Wed, Nov 12, 2008 at 12:55 PM, Paul Davis <pa...@gmail.com>wrote:
> On Wed, Nov 12, 2008 at 12:44 PM, tasman <ta...@gmail.com> 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?
Re: Seeking advice on using couchdb for rewritting a project.
Posted by Paul Davis <pa...@gmail.com>.
On Wed, Nov 12, 2008 at 12:44 PM, tasman <ta...@gmail.com> 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.
>>
>> 3) In a RDBMS such as MySQL I can use foreign keys to preserve data
>> integrity. In other words I can delete the user and due to the foreign
>> keys 'automatically' remove its profile(s), uploaded media etc. How
>> would one solve this with couchdb?
>>
>> Thanks for reading this rather lengthy email. Looking forward to the
>> thoughts and comments on this.
>>
>> All the best,
>>
>> grtz
>> BjornW
>>
>> [1] http://www.simuze.nl
>
Re: Seeking advice on using couchdb for rewritting a project.
Posted by Jan Lehnardt <ja...@apache.org>.
You are wrong =)
Cheers
Jan
--
On 12.11.2008, at 17:44, tasman <ta...@gmail.com> 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.
>
>>
>> 3) In a RDBMS such as MySQL I can use foreign keys to preserve data
>> integrity. In other words I can delete the user and due to the
>> foreign
>> keys 'automatically' remove its profile(s), uploaded media etc. How
>> would one solve this with couchdb?
>>
>> Thanks for reading this rather lengthy email. Looking forward to the
>> thoughts and comments on this.
>>
>> All the best,
>>
>> grtz
>> BjornW
>>
>> [1] http://www.simuze.nl
>
Re: Seeking advice on using couchdb for rewritting a project.
Posted by tasman <ta...@gmail.com>.
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.
>
> 3) In a RDBMS such as MySQL I can use foreign keys to preserve data
> integrity. In other words I can delete the user and due to the foreign
> keys 'automatically' remove its profile(s), uploaded media etc. How
> would one solve this with couchdb?
>
> Thanks for reading this rather lengthy email. Looking forward to the
> thoughts and comments on this.
>
> All the best,
>
> grtz
> BjornW
>
> [1] http://www.simuze.nl