incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Seeking advice on using couchdb for rewritting a project.
Date Wed, 12 Nov 2008 23:08:14 GMT

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
> <bradswinfrey@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 <dean@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 <tasman.main@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
>


Mime
View raw message