You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Noah Slater <ns...@apache.org> on 2009/02/02 11:21:54 UTC
Re: Simple erlang plugins (was Re: couch_gen_btree: pluggable
storage / tree engines)
This sounds pretty good.
On Mon, Feb 02, 2009 at 04:10:56PM +1030, Antony Blakey wrote:
> -C clean the plugins list
What does this do? I think it needs more explanation.
> -D add all the plugins in $DEFAULT_PLUGIN_DIR
> -G DIR add all the plugins in DIR
> -P DIR add the plugin DIR
Why have you chosen all capitals?
--
Noah Slater, http://tumbolia.org/nslater
Re: Simple erlang plugins (was Re: couch_gen_btree: pluggable storage
/ tree engines)
Posted by Ben Browning <be...@gmail.com>.
To spark some additional conversation around plugins, is there a clear
idea how we would handle plugin X that also uses plugin Y? For
example, I could see the Erlang API, the partitioning/clustering
functionality, and individual pieces of the clustering as additional
plugins (consistent hashing algorithm being the immediately obvious
one). The partitioning would depend on the Erlang API and a consistent
hashing plugin being configured.
For now I'm just throwing additional modules in the src/couchdb
directory in my git branch but there are enough modules in there it
makes me hesitate to add more. We could separate these into multiple
folders by using Erlang packages, but a plugin system could accomplish
the same goal and provide additional benefit for 3rd-party plugins.
It's not a pressing priority, but getting a plugin system in-place
would better allow for 3rd-party development around CouchDB and make
it easier to release and version functionality separately from the
core app.
Ben
Re: Simple erlang plugins (was Re: couch_gen_btree: pluggable storage
/ tree engines)
Posted by Chris Anderson <jc...@apache.org>.
On Mon, Feb 2, 2009 at 4:39 AM, Antony Blakey <an...@gmail.com> wrote:
>
> On 02/02/2009, at 10:34 PM, Jan Lehnardt wrote:
>
>>
>> On 2 Feb 2009, at 12:45, Antony Blakey wrote:
>>
>>>
>>> On 02/02/2009, at 10:09 PM, Noah Slater wrote:
>>>
>>>> That's fine with me. (Says the man who's not going to develop it.)
>>>
>>> Unfortunately requiring a bigger commitment to this feature than I can
>>> manage at this time.
>>
>> I hope you can push for an agreed-upon design and give a rough todo list
>> and maybe start with it and leave open work items with a good description
>> in JIRA for others to pick up. Would that work?
>
> It's just a matter of doing in erlang what I did in the script, finding out
> how to extend the load path. Hopefully my implementation shows how
> conceptually trivial it is. I agree with Noah about the configuration issue.
> Probably the only trick is that you need to load the config to find the
> plugins and then load more config from each plugin.
>
> I need to focus on the transactional _bulk_docs issue, and then the filename
> patch - that's a 0.9 blocker.
>
Yes, I think having this thread open which lays out the possibilities
is good work as long as we can avoid losing them to history by the
time we are ready to implement the plugin thing.
I think dropping a patch in Jira with a someday/maybe priority is th
best way to let us pick back up when the time comes.
--
Chris Anderson
http://jchris.mfdz.com
Re: Simple erlang plugins (was Re: couch_gen_btree: pluggable storage / tree engines)
Posted by Jan Lehnardt <ja...@apache.org>.
On 2 Feb 2009, at 13:39, Antony Blakey wrote:
>
> On 02/02/2009, at 10:34 PM, Jan Lehnardt wrote:
>
>> I hope you can push for an agreed-upon design and give a rough todo
>> list
>> and maybe start with it and leave open work items with a good
>> description
>> in JIRA for others to pick up. Would that work?
>
> It's just a matter of doing in erlang what I did in the script,
> finding out how to extend the load path. Hopefully my implementation
> shows how conceptually trivial it is. I agree with Noah about the
> configuration issue. Probably the only trick is that you need to
> load the config to find the plugins and then load more config from
> each plugin.
>
> I need to focus on the transactional _bulk_docs issue, and then the
> filename patch - that's a 0.9 blocker.
Great, thanks. Focus is good.
Cheers
Jan
--
Re: Simple erlang plugins (was Re: couch_gen_btree: pluggable storage / tree engines)
Posted by Antony Blakey <an...@gmail.com>.
On 02/02/2009, at 10:34 PM, Jan Lehnardt wrote:
>
> On 2 Feb 2009, at 12:45, Antony Blakey wrote:
>
>>
>> On 02/02/2009, at 10:09 PM, Noah Slater wrote:
>>
>>> That's fine with me. (Says the man who's not going to develop it.)
>>
>> Unfortunately requiring a bigger commitment to this feature than I
>> can manage at this time.
>
> I hope you can push for an agreed-upon design and give a rough todo
> list
> and maybe start with it and leave open work items with a good
> description
> in JIRA for others to pick up. Would that work?
It's just a matter of doing in erlang what I did in the script,
finding out how to extend the load path. Hopefully my implementation
shows how conceptually trivial it is. I agree with Noah about the
configuration issue. Probably the only trick is that you need to load
the config to find the plugins and then load more config from each
plugin.
I need to focus on the transactional _bulk_docs issue, and then the
filename patch - that's a 0.9 blocker.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
The intuitive mind is a sacred gift and the rational mind is a
faithful servant. We have created a society that honours the servant
and has forgotten the gift.
-- Albert Einstein
Re: Simple erlang plugins (was Re: couch_gen_btree: pluggable storage / tree engines)
Posted by Jan Lehnardt <ja...@apache.org>.
On 2 Feb 2009, at 12:45, Antony Blakey wrote:
>
> On 02/02/2009, at 10:09 PM, Noah Slater wrote:
>
>> That's fine with me. (Says the man who's not going to develop it.)
>
> Unfortunately requiring a bigger commitment to this feature than I
> can manage at this time.
I hope you can push for an agreed-upon design and give a rough todo list
and maybe start with it and leave open work items with a good
description
in JIRA for others to pick up. Would that work?
Cheers
Jan
--
Re: Simple erlang plugins (was Re: couch_gen_btree: pluggable storage / tree engines)
Posted by Antony Blakey <an...@gmail.com>.
On 02/02/2009, at 10:09 PM, Noah Slater wrote:
> That's fine with me. (Says the man who's not going to develop it.)
Unfortunately requiring a bigger commitment to this feature than I can
manage at this time.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
A Buddhist walks up to a hot-dog stand and says, "Make me one with
everything". He then pays the vendor and asks for change. The vendor
says, "Change comes from within".
Re: Simple erlang plugins (was Re: couch_gen_btree: pluggable
storage / tree engines)
Posted by Noah Slater <ns...@apache.org>.
On Mon, Feb 02, 2009 at 10:06:48PM +1030, Antony Blakey wrote:
>
> On 02/02/2009, at 9:48 PM, Noah Slater wrote:
>
>> I think I agree with a comment earlier in this thread. I don't think
>> command
>> options are the place for this type of configuration. Ideally, you'd
>> want all
>> the configuration in the ini file.
>
> That means that the plugin system needs to be written in CouchDB itself,
> rather than being a lightweight launch-time facility.
That's fine with me. (Says the man who's not going to develop it.)
--
Noah Slater, http://tumbolia.org/nslater
Re: Simple erlang plugins (was Re: couch_gen_btree: pluggable storage / tree engines)
Posted by Antony Blakey <an...@gmail.com>.
On 02/02/2009, at 9:48 PM, Noah Slater wrote:
> I think I agree with a comment earlier in this thread. I don't think
> command
> options are the place for this type of configuration. Ideally, you'd
> want all
> the configuration in the ini file.
That means that the plugin system needs to be written in CouchDB
itself, rather than being a lightweight launch-time facility.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
The ultimate measure of a man is not where he stands in moments of
comfort and convenience, but where he stands at times of challenge and
controversy.
-- Martin Luther King
Re: Simple erlang plugins (was Re: couch_gen_btree: pluggable
storage / tree engines)
Posted by Noah Slater <ns...@apache.org>.
On Mon, Feb 02, 2009 at 09:31:36PM +1030, Antony Blakey wrote:
>>> -D add all the plugins in $DEFAULT_PLUGIN_DIR
>>> -G DIR add all the plugins in DIR
>>> -P DIR add the plugin DIR
>>
>> Why have you chosen all capitals?
>
> Because all the obvious lower case options have been used. I wanted to
> use long options, but the shell getopts doesn't allow it.
I think I agree with a comment earlier in this thread. I don't think command
options are the place for this type of configuration. Ideally, you'd want all
the configuration in the ini file. If you really need to override some ini file
setting, maybe using an environment variable would be the way forward.
Bottom line: I want to keep the number of command line options small.
--
Noah Slater, http://tumbolia.org/nslater
Re: Simple erlang plugins (was Re: couch_gen_btree: pluggable storage / tree engines)
Posted by Antony Blakey <an...@gmail.com>.
On 02/02/2009, at 8:51 PM, Noah Slater wrote:
> This sounds pretty good.
>
> On Mon, Feb 02, 2009 at 04:10:56PM +1030, Antony Blakey wrote:
>> -C clean the plugins list
>
> What does this do? I think it needs more explanation.
clear the plugin list.
The plugin list is by default all the plugins in $DEFAULT_PLUGIN_DIR. -
C clears the list, either to run without plugins, or as a precursor to
using -D -G -P in some order to define a specific plugin ordering and/
or load additional plugins from non-default locations.
>> -D add all the plugins in $DEFAULT_PLUGIN_DIR
>> -G DIR add all the plugins in DIR
>> -P DIR add the plugin DIR
>
> Why have you chosen all capitals?
Because all the obvious lower case options have been used. I wanted to
use long options, but the shell getopts doesn't allow it.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies.
-- C. A. R. Hoare