incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <antony.bla...@gmail.com>
Subject Re: Architectural advice requested, and some 1.0 suggestions.
Date Wed, 05 Nov 2008 01:08:41 GMT
Thanks Paul.

On 05/11/2008, at 11:09 AM, Paul Davis wrote:

> This is gonna be quick as I'm getting to go watching the election
> coverage

As are we in the rest of the world.

> 1) Pretty sure when you iterate over _all_docs_by_seq, each document
> should have a _deleted=true member if it's been deleted, no reason to
> check the database if it was deleted. That's not to say that there may
> be extra information that could be passed to the update processes. (On
> second read through I'm starting to doubt this now. It could be that
> you end up getting this from the _all_docs. My general thing is read
> 500 or so rows from _all_docs_by_seq and then do a multi-get on those
> 500 docs etc. so the deleted info might come from _all_docs).

Good advice, thanks.

> 2) Currently trunk does have an easy method for registering external
> erlang code easily via the different daemons and httpd handlers. Two
> things though, the startup script needs to have  a couple extra
> parameters for telling erlang to load other directories than its own
> lib directory. (Or maybe possible config directives? Not sure on
> erlang's runtime directory path support mechanism)

It's the packaging mechanism (load path etc) that I'm primarily  
concerned with.

> Also, there are
> parts of the api that will probably need to be extended for you to get
> all the bells and whistles you're wanting. (ie, an erlang
> udpate_notification handler or some such)

The API available to plugins (as opposed to 'read all the code') is  
critical here so that plugins don't get entangled in the innards,  
which is not only bad for plugin writers, but also makes evolution  
likely to break plugins.

And of course documentation is an absolute requirement for wide  
adoption.

> 3) This would be alleviated I think if we flesh out the process for
> adding plugins etc. Your updater/query code would all be in one module
> and have access to everything required.

Yes. And +1 for this to be done sooner rather than later.

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Success is not the key to happiness. Happiness is the key to success.
  -- Albert Schweitzer


Mime
View raw message