On Thu, Sep 27, 2012 at 5:33 PM, Bob Dionne <[email protected]> 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 <[email protected]> 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 >
