couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: REST, Hypermedia, and CouchApps
Date Mon, 09 Mar 2009 17:42:46 GMT
On Mon, Mar 9, 2009 at 1:40 PM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
> On Mon, Mar 9, 2009 at 12:58 PM, Christopher Lenz <cmlenz@gmx.de> wrote:
>> On 05.03.2009, at 23:34, Jan Lehnardt wrote:
>>>
>>> On 5 Mar 2009, at 21:38, Christopher Lenz wrote:
>>>>
>>>> Actually, I'd go even further, and suggest that the "show" and "list"
>>>> features should be part of that CouchApp plugin, and not actually included
>>>> with CouchDB itself. You really only need those features when you're
>>>> developing CouchApp-style applications. Moving them into a corresponding
>>>> plugin would help keep CouchDB itself lean and clean.
>>>
>>> show and list are useful in the non-couchapp case. a list gives you
>>> RSS/Atom feeds on views (say blog posts or events) for free. a show would
>>> help you to mangle your data for other systems that e.g. like to consume
>>> XML. I like that this can be done without a middleware layer.
>>>
>>> I'm +1 on modularizing additional features on the Erlang level, but show &
>>> list I'd consider core CouchDB and -1 on making them optional.
>>
>> "core" is a strong word for something where you just said "I like that this
>> can be done without a middleware layer".
>>
>> I'm not convinced. I'm talking about the case where you already have
>> "middleware" anyway -- if you don't, you have a CouchApp-style app.
>> Generating Atom, HTML, and such is pretty darn convenient for me with Python
>> and Genshi, I don't think moving that into CouchDB show/list functions will
>> buy me anything. And since I'm hiding CouchDB itself behind that middleware
>> I'd have to proxy the CouchDB responses through it anyway.
>>
>> Note that I'm just stating my opinion, I knew it'd be controversial,
>> especially with the CouchApp fans :P
>> I'm totally willing to accept the majority preference here, which seems
>> pretty clearly in favor of show/list in core.
>>
>> Cheers,
>> --
>> Christopher Lenz
>>  cmlenz at gmx.de
>>  http://www.cmlenz.net/
>>
>>
>
> My personal opinion is that we should strive towards making CouchDB
> modular and easily configurable. (ie, no need to stop the server and
> edit an ini file). As part of this work I could see having a contrib
> directory of modules that are included in trunk and available on any
> default install. Giving a nice page in Futon that was all pretty and
> listed the available modules that could be enabled and disabled at
> runtime would be awesome.
>
> Following that, the _list/_show bits seem like they would fit quite
> nicely into such a framework as a poster child of the modular couch.
> And we could even ship couchdb with _show/_list turned on by default
> if the community so desires it.
>
> Also of note is that the _show/_list code is pretty self contained and
> doesn't affect the deeper internals other than to point out where
> things could be made a bit more generic for reuse which has been
> beneficial so far.
>
> HTH,
> Paul Davis
>

I forgot to mention I'm a 0 on whether _show/_list is part of CouchDB
'core'. I'd be +1 on making sure they get distributed with CouchDB
though, the naming thing I leave to other people. Hopefully some
future updates to make us more OTP compliant will make this definition
game disappear completely.

Mime
View raw message