+1 for a refactor.
GeoCouch duplicates a lot of code. I tried to keep the names in as
similar (though meaningful) to the original ones as possible to see
where the duplicated code is.
I would love to see that everyone who wants a new kind of indexer just
need to provide the data structure and all the design document handling,
updater (group) handling, list functions etc is done automatically.
Cheers,
Volker
On 20.08.2010 13:06, Robert Dionne wrote:
+1
I would change the or in the subject line to and, .ie. do both :)
I think this is an excellent idea and a good time to start this. At a
conceptual level CouchDB is dirt simple internally. This fact and it's use of
Erlang in my opinion should be seen as it's main advantage. One way to leverage
that advantage is to enable programmers who want to extend couch. I know of at
least three projects [1,2,3] that have done this. A good measure of a
successful refactor would be how much code these projects could throw away.
In my terminology prototype [3] I'm currently using bitcask for persistence so
I basically only extend the HTTP front end piece and need programmatic access
to the b-tree storage layer. All this needs to be is some sort of mapping that
let's one run a function over the b-tree, support for ranges, and access to
changes.
Doing this is a thankless task, anyone already deeply familiar with the
internals would likely have little *interest* (academic, financial, etc..) in
it. CouchDB runs on phones now and in the cloud which is awesome and of course
a strong argument to maintain the simple design. As the complexity of the code
base increases however, the use of Erlang becomes a barrier to entry.
Best,
Bob
[1] http://github.com/normanb/couchdb-multiview
[2] http://github.com/vmx/couchdb
[3] http://github.com/bdionne/bitstore
On Aug 20, 2010, at 5:09 AM, Benoit Chesneau wrote:
Hi all,
I work a lot these days around the httpd code and the more I work on
the more I think we should refactor it to make it easier to hack and
extend. There is indeed a lot of code in one module (couch_httpd_db)
and recent issue like vhost and location rewriting could be easier to
solve if we had an http layer more organized in my opinion.
Actually we do (in 1.0.1 or trunk) :
request -> couch_httpd loop -> request_handler -> check vhost and
eventually rewrite url -> request_int -> request_db -> request
doc|request _design | request attachment | request global handler |
request misc handler
with extra level : request_design -> rewrite handler|
show|lists|update\lview ... and request_int that catch all errors and
has the responsibility to send errors if anything happend and wasn't
catched on other layers.
It could be easier. We could do it more resource oriented for example
than it is. 1 module, 1 resource. Refactoring httpd code would also
allow us to reuse more code than we do actually maybe by wrapping api.
How :
- Some times ago we started to port it using webmachine with davisp,
but we didn't finish. Maybe it's a good time ? Or do we want to follow
another way ?
- If we go on this refactoring it could be also a good time to split
couchdb in different apps : couchdb-core and couchdb foe example
(maybe couchdb-appengine ?) so we could develop independantly each
levels and make code history cleaner.
Thoughts ?
- benoit
