couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Part1: What's up dev? About energy.
Date Thu, 27 Sep 2012 19:55:31 GMT
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 interesting. I'm impressed
how prolific you are.

thanks :)

>
> 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.

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 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.

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 and 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=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.

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), 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