Mailing-List: contact couchdb-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of antony.blakey@gmail.com
 designates 209.85.200.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=ZBzZDKLjC8R1pVbJ/O5V+m3HOQkToUwJg6Ymiz8gspaDTahQ/UvKHQluAPcEvIMEJD
         0Up1r/si0OrhgLOUu1u8Fmhzj3R41lYwomRI6ioQm93pFNmXbiNdX0LTXA6Lzh1uPVI2
         2BlvbIdXgwCnGpu4OICZUYeT+sAnWr/eQjx1g=
Message-Id: <511FB835-695F-41DB-890E-8985AAF198FB@gmail.com>
From: Antony Blakey <antony.blakey@gmail.com>
To: couchdb-dev@incubator.apache.org,
 Paul Davis <paul.joseph.davis@gmail.com>
In-Reply-To: <e2111bbb0811041639o291bae40hbd41c6176bf27fe1@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Architectural advice requested, and some 1.0 suggestions.
Date: Wed, 5 Nov 2008 11:38:41 +1030
References: <4C915D97-E639-4FEC-BCB4-F8E6B42FE7AD@gmail.com>
 <e2111bbb0811041639o291bae40hbd41c6176bf27fe1@mail.gmail.com>

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