couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject Re: Writing a Plugin : know couchdb core
Date Sat, 14 Dec 2013 09:41:53 GMT
Hey Franck!

On Sat, Dec 14, 2013 at 1:02 PM, Franck Eyraud
<> wrote:
> It seems that plugin discussions don't create passionate debates... It's a
> pity because it is really a good feature, and since from what I understood
> taht the couchdb core might be reduced in the future, plugins will be always
> used more.

There is nothing to discuss - it's very useful plugin and great idea
to implement! Don't think that nobody cares because there was no
responses from devs: most of them on CouchHack now and focused on
code, fork merges and CouchDB (:

> Maybe creating a plugin is not a in itself problem. I watched the
> interesting talk[1] from Jason Smith which is a very good start. And it made
> me realize that writing a plugin is in fact equivalent to writing a bit of
> code in couchdb core.
> So what I need is to learn what a couchdb developer knows : couchdb
> architecture and API.
> Is there any resource online where I can learn this stuff ? A quick start
> guide to develop in couchdb (especially for people who never used erlang
> before) ? Or is the only way to dig inside couchdb git tree and try to
> understand ? Before doing this, I want to be sure I won't loose too much
> time. So please people who entered the couchdb project later, how did you
> reach your level ?

Actually, there are plans to have such in our docs for developers
guide section, but currently there is no any "official" information
about. But we're working on to fix this (: However, you may found some
useful blog posts over Internet and projects that are already hacked
into CouchDB. For instance, you would love to see similar project that
implements custom authentication with 3d party service:

About how to start...locate interesting module, take a look on his
commit history, find out interesting functions, write some tests about
to check and ensure in his behaviour or read existed ones. After that,
create your own test case - it will be all "red", but thats ok. Trying
to make it "green" will be your goal during developing or hacking.
Don't make it too detailed from start, but you'll be happy to extend
and improve it while adding new functions and featured. Not the best
plan, but something to start from (; But anyway, don't fear erlang,
don't fear write stuff and see it broken: in most cases it's easy to
fix things quickly after 5 minutes googling or reading erlang docs or

Happy hacking!



View raw message