Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of bchesneau@gmail.com designates
 209.85.215.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <541CFDFD-D1D7-4BDE-A98F-395F8FD6BBF4@dionne-associates.com>
References: 
 <CAJNb-9o+A7GMXGe3FdBkmX6zb2miRvScX91qcDnosD1JRTrzxw@mail.gmail.com>
	<541CFDFD-D1D7-4BDE-A98F-395F8FD6BBF4@dionne-associates.com>
Date: Thu, 27 Sep 2012 21:55:31 +0200
Message-ID: 
 <CAJNb-9qV1Lzvu5mVJhPAFn1v3x93j2-gefw=mWkcZKN7ikQ3Yw@mail.gmail.com>
Subject: Re: Part1: What's up dev? About energy.
From: Benoit Chesneau <bchesneau@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 27, 2012 at 5:33 PM, Bob Dionne
<dionne@dionne-associates.com> wrote:
> 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 intere=
sting. I'm impressed how prolific you are.

thanks :)

>
> I'd definitely love to see simpler internals and a better separation of c=
oncerns, 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 mu=
d, but I'm not a web programmer, I'm sure there's issues I'm missing.

Not sure as well. Actually a more efficient js evaluation would solve
most of the problem we have and open new possibilities...

>
> 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 gra=
phs. Not large social graphs such as "who likes who", but rather graphs tha=
t 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 cou=
ch_store (not to be confused with the one from Couchbase) that would give m=
e 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 u=
seful. 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.

That would be awesome indeed. It doesn't need to solve all the
problems imo. I also have a look on bindings like the xapian one:

https://github.com/arcusfelis/xapian-erlang-bindings

unfortunately xapian is under GPL...

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

cool :)
>
> 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?

Can be yes :) I think we may need a way to merge couchbeam/fabric so
it can be used for the replication and other remote needs as well. I
am working on such thing. I am trying to understand these days how
rexi usage could also be done on top of http/

> It seems to me a single instance is just the special case of R=3DW=3DQ=3D=
N=3D1. I know PaulD, BobN, and others have lots of good ideas here and I th=
ink we'll all soon be in the middle of it.

Can be yes. Not sure how it would be optimized or to rebalance to a
new node after . But indeed ....

>
> 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), bigcouc=
h
>> 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=EEt
>