incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Dionne <dio...@dionne-associates.com>
Subject Re: Part1: What's up dev? About energy.
Date Thu, 27 Sep 2012 15:33:18 GMT
Hi Benoit,

I can understand your view and to some extent share your concerns. 

I took a look at the refuge project and things like couch_core are interesting. I'm impressed
how prolific you are. 

I'd definitely love to see simpler internals and a better separation of concerns, especially
with respect to couchapps. I've always been enamored of the idea and wonder why the implementation
seems to get so mired in the mud, but I'm not a web programmer, I'm sure there's issues I'm
missing.

My hobby interest in couchdb is primarily as a document store. I'd still like to see a native
full text indexer and I'm also interested in a simple triple store whose tuples are doc ids,
mainly to enable algorithms over graphs. Not large social graphs such as "who likes who",
but rather graphs that are used in description logics and proof theory, of order a million
nodes with high connectivity. I toyed with pulling out the essentials into a couch_store (not
to be confused with the one from Couchbase) that would give me something like a bitcask API,
if that makes sense. For me something like that with the ability to load other gen_servers
as needed would be really useful. CouchDB is kind of there now in that regard, but the internals
still need a lot of work. Anyway I recognize this is a niche use case, though a native FTI
might be of general interest.

Anyway, sorry to be so vague. I'm definitely +1 on better OTP/rebar use and so forth and happy
to help as I can on the internals.

With respect to BigCouch, do you think Fabric is the best way to provide a unified API for
both the single instance and clustered cases? It seems to me a single instance is just the
special case of R=W=Q=N=1. I know PaulD, BobN, and others have lots of good ideas here and
I think we'll all soon be in the middle of it.

Regards,

Bob

On Sep 24, 2012, at 5:20 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:

> What's up devs?
> 
> Following our last discussion with @nslater on twitter, I wanted to say
> a quick HI on the mailing-list. This mail is splitted in 2 parts. A long
> time really. These days I miss what make me enjoy CouchDB at the
> beginning. The energy you could feel on the chan and sometimes IRL. The
> time when anyone was aware of who was working on a feature. Which
> feature was in progress. Today IRC is more like a support channel where
> sometimes ideas emerge but you don't feel they are very supported. There
> are private discussion somewhere.  But well they are... private. Same
> for tickets. We see tickets but more often no real incentive from each
> others (and I am to blame too) to fix them.
> 
> Today to be honnest, this lack of energy annoys me a lot. This is quite
> more important than the rest. At least for me. I don't have 4 devs on
> the projects working with me in my office where I can speak with each
> other about possible fixes and such .. Communication inside the project
> is  really important. Apache CouchDB is an opensource project
> distributed around the world (at least 2 continents).
> 
> Anyway I still keep my confidence in the project. I know there have been
> lot of codes developped around. Today if we don't count the couchbase
> fork (wich is still named couchdb and all...) there are 2 friendly forks I'm
> aware of couchdb: bigcouch, refuge.
> 
> Bigcouch was announced to be merged in. But since then we don't know as
> couchdb devs how it will be. How can we keep couchdb working standalone
> and on a cluster. It blocks everything else today for me since I don't
> know if I will work on a cluster or still can continue to think I can
> use couchdb standalone on one node (and possiblit migrate to the
> cluster thing easily). I didn't see anything about in
> bigcouch recently as well. . As a CouchDB developper I would like to see
> a branch in couchdb so we can hack on all together or just review or
> document.
> 
> Rcouch my own fork which has the following features:
> 
> - OTP compliant (build an erlang release, support hot upgrades), bigcouch
> is as well. Today couchdb isn't really erlangish and is based on
> autotools
> - static build support. Packages for deb, rpm, macosx, arm platforms
> - View changes: get changes in an ndex in real time
> - Replication using view changes
> - couch_randomdoc : pick a random document inside a db or a view
> - dnssd : discover couchdb over bonjour in your lan
> - upnp : make couchdb easily accessible on the net
> - refuge_spatial: fork of geocouch adapted to use latest couch_index.
>  (note that a version also exists for bigcouch)
> - HTTP api based on ranch and cowboy (using mochicow for the
>  transition). more stable and efficient HTTP handlers
> - doc read validation (like update validation)
> - dropbox features (anyone can upload only readers or admins can read
>  doc uploaded)
> - some replication fixes.
> - no refcount db , using a patch from @davisp similar to the one in
>  bigcouch
> - ..
> 
> And coming this week: view merge & cors.
> 
> I would like to merge it in couchdb as well. But I don't know how. And
> each time I asked for having a discussion on it it fails because some
> were busy or anything (but never came back). Can we put a roadmap for
> that and start to put the code online?
> 
> 
> Second part about couchapps in next mail.
> 
> - benoƮt


Mime
View raw message