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: couch_gen_btree: pluggable storage / tree engines
Date Sun, 01 Feb 2009 06:37:07 GMT

On 01/02/2009, at 4:33 PM, Chris Anderson wrote:

> You keep talking about these modifications.

I supplied a github branch with the patch for plugins, and I provided  
the ruby source for an external indexer. Hopefully "put up or shut up"  
is satisfied :)

> We're anxious to see your
> db-name patch

I supplied a github branch with that patch. The view server was  
changed after I did it, which requires re-working the patch, and there  
were some other requests which I agreed to (slugs & slashes). The  
transaction issue is more important to me, so I'm waiting to see if I  
need to support a private branch for that before I revisit the unicode- 
file-name code.

> , and we've already added seq id to external.

When I posted the ruby indexer I noted that the full db-info is now  
provided per request - subsequent discussion prompted the db UUID  
thread idea. I haven't checked the code to determine the semantics of  
the purge_seq field - it may be enough to *catch* purges, although I  
think a purge hook would be a very useful optimization to ensure that  
externals don't require a full sweep.

> DB uuids
> are an interesting topic as well, but more interesting is code.

I was providing a perspective for Martin Scholl, my point being that  
what he wants is doable now, without having to make the canonical  
store pluggable (which IMO is neither feasible nor desirable).

Even without DB uuids, external indexing is still a very useful model.

> It's pretty flexible already, maybe just some path globs for `make
> plugins` is all it would take to get a plugins/helpers convention into
> the build. We could add starting of apps (crypto, ibrowse, etc) to
> default.ini. Then you'd probably have everything you need to add new
> modules to the couch system.

Yes, as I say, I supplied a gihub branch for using such modules. Even  
with no other changes, it's useful right now, and laughably trivial.

As far as core modularity is concerned, I don't know if it's feasible  
to patch that from outside the committers group because of the  
coordination required. I may be wrong.

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

He who would make his own liberty secure, must guard even his enemy  
from repression.
   -- Thomas Paine



Mime
View raw message